[PAC][libc++] Fix build with `ptrauth_calls` feature (#211033)
After partial revert of #208330 in #209928, the libcxx build started
failing because of missing `<cstdint>` include required for `uintptr_t`
declaration used only by code behind `ptrauth_calls` feature check. See
https://lab.llvm.org/buildbot/#/builders/227/builds/3358
This patch adds the missing include.
[flang][OpenMP] Reland implement collapse for imperfectly nested loops (#211000)
Reland of combined #208528 and #210753.
Fixes #199092 - Flang previously rejected intervening code between
associated loops in a collapsed nest (e.g. collapse(2) with statements
between the outer and inner DO). This patch removes that restriction and
implements correct lowering.
[mlir-c] Test the failure path of the 1:N type conversion callback
Adds a test that registers a 1:N conversion function returning
MlirTypeConverterConversionStatusFailure. Because it is tried before the
i32 -> (i16, i16) conversion, the failure must abort the whole conversion
(rather than falling back), leaving the IR unchanged -- the behavior that a
plain decline would not produce.
[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] 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] Use a tri-state status enum for the type conversion callback
MlirTypeConverterConversionCallback returned MlirLogicalResult and used a
null convertedType as a second failure sentinel, which could only express
success or "try another conversion" -- and conflated the C++ decline
(std::nullopt) and hard-failure (failure()) states.
Introduce MlirTypeConverterConversionStatus (Success/Failure/Declined) and
return it from the callback instead, mapping the three states to success(),
failure(), and std::nullopt respectively. Update the Python binding and the
C API test callback accordingly.
Add a C API unit test (testTypeConverterConversionStatus) exercising all
three status values through mlirTypeConverterConvertType.
[OpenACC/CIR] Remove std::transform_inclusive_scan use (#211076)
This seemingly is only added for GCC libstdcxx 11.1's C++17 support, but
our support matrix is 7.4. Replace it with a loop that implements the
same requirement.
[SLP]Make the instruction-count check loop-aware
Raw getNum{Scalar,Vector}Insts() counted one-time, LICM-hoisted
broadcasts/buildvectors against the loop body, rejecting profitable loop
trees (508.namd_r). Weight each entry by its loop-nest trip
count and drop nest-invariant ones; flat code is unchanged (scale 1).
Fixes #207572
Reviewers: bababuck, RKSimon, hiraditya
Pull Request: https://github.com/llvm/llvm-project/pull/210074
[SelectionDAG][GlobalISel] Move `to_tframeindex` & `renderFrameIndex` from targets into common code. (#210896)
Consolidates the multiple copies across the targets of the
`to_tframeindex` `SDNodeXForm` (frame index => target frame index) and
its GISel counterpart/equiv `renderFrameIndex`, moving them into
appropriate common areas.
As suggested/requested in
https://github.com/llvm/llvm-project/pull/206885#discussion_r3504014131
contigmalloc.9: Note that M_WAITOK may still return NULL
Reviewed by: markj, bapt
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58382
[DTLTO] Forward loop interchange to DTLTO remote compilations (#208591)
Recent upstream LLVM changes enabled `LoopInterchangePass` by default
through `PipelineTuningOptions`. TLTO observes that state directly from
the LTO config, but DTLTO was not forwarding the equivalent Clang option
to the remote compiler. As a result, TLTO could run loop interchange
pass while DTLTO did not, producing codegen differences for
configurations that exposed profitable/legally interchangeable loops.
Note that this was a pre-existing issue, the change in default has
simply exposed it.
Forward `C.PTO.LoopInterchange` as `-floop-interchange` when
constructing the common DTLTO remote compiler options. Extend the
testing to check that the SN-DBS remote command line includes the
forwarded option.
The code for forwarding such options is only intended as a temporary
measure. A more comprehensive solution is in discussion here:
https://discourse.llvm.org/t/synchronizing-lto-code-generation-configuration-between-clang-and-lld-dtlto
