[DirectX] Fix `--dx-embed-debug` flag dependency (#210513)
This patch moves the definition of `cl::opt<std::string> PdbDebugPath`
from `DXContainerGlobals.cpp` to `DXILWriter/DXILWriterPass.cpp`,
reversing the dependency.
Fixes the layering violation in #204166.
[mlir-c] Expose hard-failure state in 1:N type conversion callback
The 1:N conversion callback returned MlirLogicalResult, which the binding
could only map to success or nullopt (try-another), leaving the C++
failure() state (fail without trying another conversion) unreachable.
Return a MlirTypeConverterConversionStatus enum instead, with Success,
Failure, and Declined states mapped to success(), failure(), and
std::nullopt respectively. Add a test covering the hard-failure path.
[mlir-c] Expose hard-failure state in 1:N type conversion callback
The 1:N conversion callback returned MlirLogicalResult, which the binding
could only map to success or nullopt (try-another), leaving the C++
failure() state (fail without trying another conversion) unreachable.
Return a MlirTypeConverterConversionStatus enum instead, with Success,
Failure, and Declined states mapped to success(), failure(), and
std::nullopt respectively. Add a test covering the hard-failure path.
[mlir-c] Value-initialize MlirConversionPatternCallbacks in Python bindings
The Python conversion-pattern binding left the struct default-initialized,
so the newly-added optional matchAndRewrite1ToN field held an indeterminate
pointer. The driver's null check then read garbage and jumped into it,
segfaulting mlir/test/python/rewrite.py. Value-initialize the struct so
optional callbacks default to null.
[mlir-c] Add 1:N TypeConverter conversion and materialization bindings
Builds on the source/target materialization C bindings:
- Target materialization callbacks now receive `originalType` (split from the
previously-shared source/target callback typedef), exposing a documented C++
capability that was otherwise unreachable from C.
- 1:N type conversion: `mlirTypeConverterAdd1ToNConversion` plus an opaque
results accumulator (`MlirTypeConverterConversionResults` /
`mlirTypeConverterConversionResultsAppend`). A declining callback's appended
types are rolled back so the driver's "try the next conversion" invariant
holds.
- 1:N target materialization: `mlirTypeConverterAdd1ToNTargetMaterialization`,
whose callback fills a caller-allocated `outputs` buffer. A success that
leaves any output null is treated as a decline rather than handing the driver
a null-containing result.
- `mlirConversionPatternRewriterReplaceOpWithMultiple` for 1:N value
replacement, which can drive a source materialization with nInputs > 1.
- An optional `matchAndRewrite1ToN` callback on `MlirConversionPatternCallbacks`
[9 lines not shown]
[mlir-c] Fix -Wmissing-field-initializers in rewrite.c test
The new matchAndRewrite1ToN field left three existing
MlirConversionPatternCallbacks initializers under-initialized, which
fails the CI build under -Werror=-Wmissing-field-initializers.
[mlir-c] Use a status enum for the type conversion callback
The 1:1 conversion callback returned MlirLogicalResult and encoded the
three C++ conversion states implicitly: returning failure meant "try
another conversion", while returning success with a null out-parameter
meant a hard failure. This dual encoding was easy to misuse and the doc
comment conflated the two.
Return a MlirTypeConverterConversionStatus enum with explicit Success,
Failure (do not try another), and Declined (try another) states, and add
a test covering the decline-fallback and hard-failure paths.
[CIR][AMDGPU] Add support for AMDGCN frexp_mant builtins (#198121)
Adds codegen for the following AMDGCN frexp mantissa builtins:
- __builtin_amdgcn_frexp_mant (double)
- __builtin_amdgcn_frexp_mantf (float)
- __builtin_amdgcn_frexp_manth (half)
These are lowered to the corresponding `llvm.amdgcn.frexp.mant`
intrinsic.
[NFC][ELF] Remove unused R_TLS*_HINT RelExprs (#210519)
As of 5e87f8147d68 ("[ELF] Add target-specific relocation scanning for
PPC32 (#181517)") these are never generated, and as of 46d29d43ba8e
("[ELF] Remove unused handleTlsRelocation (#184951)") these are not even
handled anywhere.
[NFC][ELF] Remove unused R_TLSDESC_CALL RelExpr (#210518)
As of 4ea72c1e8cbd ("[ELF] Add target-specific relocation scanning for
RISC-V (#181332)") this is never generated, and as of 46d29d43ba8e
("[ELF] Remove unused handleTlsRelocation (#184951)") this is not even
handled anywhere.
[NFC][ELF] Remove unused R_RELAX_TLS_* RelExprs (#210517)
As of 46d29d43ba8e ("[ELF] Remove unused handleTlsRelocation (#184951)")
these are never generated.
[X86][APX] Optimize usub.sat(X,1) to cmp+adc with NDD (#208475)
When NDD is available, usub.sat(X, 1) is lowered from xor+sub+cmov (3
insns) to cmp+adc (2 insns).
All X86 tests pass.
Fixes #207888
Co-authored-by: AntonyCJ30 <cj6186609 at gmail@gmail.com>
[RISCV] Add packed narrowing convert intrinsics (#210389)
Add RISC-V P-extension packed narrowing convert header APIs for `pncvt`
and `pncvth`.
The new APIs lower through generic IR: RV32 uses truncate / logical
shift plus truncate forms, while RV64 uses existing packed unzip shuffle
forms. This reuses the existing backend lowering and TableGen aliases
rather than adding intrinsic-specific lowering.
Tests cover Clang IR generation and cross-project header assembly checks
for RV32/RV64 spec-listed mnemonics.
[Support] Improve the logic for re-raising signals (#177864)
On most systems, checking `si_pid` is not actually valid unless
`si_code` equals one of the relevant signal codes (`SI_USER`,
`SI_QUEUE`, and on some OSs, `SI_LWP`), or the signal is `SIGCHLD`. So
on e.g. NetBSD, we would misinterpret the `SIGSEGV` fault address as the
sending PID and incorrectly conclude that the signal came from a
different process.
But as far as I can tell, there's not even a valid reason for us to be
checking `si_pid != getpid()`, because the signal could very well have
been explicitly sent by another thread in the current process. So we
really just need to check `si_code` for the aforementioned signal codes.
Darwin is the exception because it just doesn't set `si_code` at all in
the case of the `SI_*` signal codes. So keep the old logic there, even
though it misses the corner case of signals sent by a thread in the
current process.
[4 lines not shown]
[IR] Make semantics of strictfp consistent (#209465)
Although the section on constrainedfp in the LangRef clearly states "All
function definitions that use constrained floating point intrinsics must
have the strictfp attribute", indicating that a function with strictfp
calls must be marked with strictfp, the general description of strictfp
does not specify this. Refine its semantics and make it so, eliminating
the inconsistency.
[orc-rt] Drop callManagedCodeAsync; tokens guard execution (#210508)
callManagedCodeSync is renamed to callManagedCode, and
callManagedCodeAsync is removed.
callManagedCodeAsync held a ManagedCodeTaskGroup token from the initial
call until the async continuation ran -- across the gap in which the
call is suspended and no managed code is executing. A token is meant to
guard managed code that is executing on a stack, so holding one across
that gap guards nothing while blocking shutdown.
callManagedCode holds a token only for the synchronous call to the
wrapped function, including anything the function runs inline on the
same thread before returning. An async function is called the same way,
with its continuation passed as an ordinary argument. Work deferred past
the function's return -- stashed, or handed to another thread -- runs on
a stack the token no longer guards; whoever later runs it is responsible
for ensuring a token covers it, acquiring one and aborting if the
acquire is denied.
[3 lines not shown]
[Clang][Interpreter] Respect default setting on Windows
MSCV does not support the -fPIC option. When it is passed, Clang falls
back to PIC level 2 on x86_64 and to a static binary on AArch64. Without
-fPIC, however, PIC is already enabled by default on both targets.
As a result, the PCH (built with the default PIC level by toolchain
hint) and the clang-repl instance (using the fallback PIC level) end up
with different PIC settings, consuming a mismatch.
Avoid passing -fPIC when targeting MSVC on Windows. This preserve the
existing semantics, since PIC is already enabled by default, while
ensuring that both the PCH and clang-repl use the same PIC level.
