4 Commits

Author SHA1 Message Date
Finn Plummer
e4e666a852
[NFC][HLSL] Replace use of clang_dxc with clang_cc1 in testing (#160359)
The use of `clang_dxc` should be contained to the
`clang/test/[Option|Driver]` directories.

`clang_cc1` is a more direct way to invoke these tests.
2025-09-23 13:18:19 -07:00
Farzon Lotfi
111af76bd7
[DirectX] add Function name to DiagnosticInfoUnsupported Msg in DXILOpLowering (#136234)
fixes #135654

In #128613 we added safe guards to prevent the lowering of just any
intrinsic in the backend. We used `DiagnosticInfoUnsupported` to do
this.

What we found was when using `opt` the diagnostic print function was
called but when using clang the diagnostic message was used.

Printing message in the clang version means we miss valuable debugging
information like function name and function type when LLVMContext was
only needed to call `getBestLocationFromDebugLoc`.

There are a few potential fixes

1. Write a custom DiagnosticInfoUnsupported so we can change the Message
just for DirectX. Too heavy handed so rejected.

2. Add the function name to the Message in DirectX code. Very simple one
line change. Downside is when using opt you see the function name twice.
But makes the clang-dxc bugs more actionable.

3. change CodeGenAction.cpp to always use the print function and not the
message directly. Downside is a bunch of innacurate information shows up
in the message if you don't specify `-debug-info-kind=standalone`.

4. add some book keeping to know which function called the intrinsic
keep a map of these so we can pass the calling function to
`DiagnosticInfoUnsupported` instead of the intrinsic. This would only be
useful if we had debug info so we could distinguish different uses of
the intrinsic by line\col number. We would also need to change from
iterating on every function to doing something like a LazyCallGraph
which is a nonstarter.

5. pick a different means of doing a Diagnostic error, because other
uses of `DiagnosticInfoUnsupported` error when we are in the body of a
function not when we see one being used like in the intrinsic case.

This PR went with a combo of option 2 & 5. Its low code change that also
only impacts the DirectX backend.
2025-04-21 10:26:27 -04:00
Justin Bogner
da17ced11b
[DirectX] Use scalar arguments for @llvm.dx.dot intrinsics (#134570)
The `dx.dot2`, `dot3`, and `dot4` intrinsics exist purely to lower
`dx.fdot`, and they map exactly to the DXIL ops of the same name. Using
vectors for their arguments adds unnecessary complexity and causes us to
have vector operations that are not trivial to lower post-scalarizer.

Similarly, the `dx.dot2add` intrinsic is overly generic for something
that only needs to lower to a single `dot2AddHalf` DXIL op. Update its
signature to match the operation it lowers to.

Fixes #134569.
2025-04-14 10:34:15 -07:00
Farzon Lotfi
16c84c4475
[DirectX] Add target builtins (#134439)
- fixes #132303
- Moves dot2add from a language builtin to a target builtin.
-  Sets the scaffolding for Sema checks for DX builtins
-  Setup DirectX backend as able to have target builtins
- Adds a DX TargetBuiltins emitter in
`clang/lib/CodeGen/TargetBuiltins/DirectX.cpp`
2025-04-07 12:06:57 -04:00