[InstCombine] Fix 0.0 / x -> 0 folds when the divisor may be zero (#202482)
SimplifyDemandedUseFPClass folded 0/x to a signed zero, guarded only on
the divisor being non-NaN. But when x==0, the result is is NaN, not 0!
Require the divisor to be never (logical) zero, unless a NaN result
isn't demanded.
[IR][NFC] Avoid unneccessary move of analysis results (#210540)
While benchmarking CycleAnalysis, I noticed that each analysis result is
constructed on the stack first and then moved to its final place on the
heap. This is unnecessary -- directly construct the analysis result in
its final place. Consequently, analysis results can be immovable.
[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.
