[AMDGPU] Fix legalization of V_PK_*64 SGPR to VGPR change (#211357)
Special case for V_PK_*64 instructions: these do not have OPSEL but SGPR
sources behave like OPSEL is set replicating low 64-bits into high. VGPR
sources in turn read actual 4 registers. To move operand from an SGPR to
a VGPR we need to replicate low half.
[docs][clang-format] Migrate generated clang-format docs to markdown
The challenge here is that the documentation is generated from Doxygen
comments in headers, `Format.h` and `IncludeStyle.h`.
First, the generator was updated to generate markdown constructs, and
then the Doxygen comments were also modified to use markdown constructs.
Mostly this means using single backticks instead of double backticks,
which is the Doxygen-native way of expressing code font blocks anyway,
so that's good.
To validate, I built the Sphinx docs and the doxygen, and I confirmed
that the generator script is idempotent, meaning it doesn't change the
markdown output. When I add a new option to clang-format, it shows up in
the help text block, so it works.
Before/after validation links:
| Source file | Before HTML | After HTML |
| --- | --- | --- |
[4 lines not shown]
[mlir][OpenACC] Support dynamic multi-rank array reductions (#211336)
Example:
```fortran
integer :: r(:,:)
!$acc parallel loop reduction(+:r)
```
In this code, the reduction accumulator has dynamic dimensions and rank
greater than one.
Fix: use runtime dimension sizes to delinearize flattened
array-reduction indices.
[docs][clang-format] Migrate generated clang-format docs to markdown
The challenge here is that the documentation is generated from Doxygen
comments in headers, `Format.h` and `IncludeStyle.h`.
First, the generator was updated to generate markdown constructs, and
then the Doxygen comments were also modified to use markdown constructs.
Mostly this means using single backticks instead of double backticks,
which is the Doxygen-native way of expressing code font blocks anyway,
so that's good.
To validate, I built the Sphinx docs and the doxygen, and I confirmed
that the generator script is idempotent, meaning it doesn't change the
markdown output. When I add a new option to clang-format, it shows up in
the help text block, so it works.
Before/after validation links:
| Source file | Before HTML | After HTML |
| --- | --- | --- |
[4 lines not shown]
[flang][acc] Permit acc routine for specific name (#211386)
After https://github.com/llvm/llvm-project/pull/211269 a generic
interface name is rejected in acc routine. This PR relaxes this by
allowing it when the interface name and the specific are the same - and
attaches the information to the specific itself.
[docs][clang-format] Migrate generated clang-format docs to markdown
The challenge here is that the documentation is generated from Doxygen
comments in headers, `Format.h` and `IncludeStyle.h`.
First, the generator was updated to generate markdown constructs, and
then the Doxygen comments were also modified to use markdown constructs.
Mostly this means using single backticks instead of double backticks,
which is the Doxygen-native way of expressing code font blocks anyway,
so that's good.
To validate, I built the Sphinx docs and the doxygen, and I confirmed
that the generator script is idempotent, meaning it doesn't change the
markdown output. When I add a new option to clang-format, it shows up in
the help text block, so it works.
Before/after validation links:
| Source file | Before HTML | After HTML |
| --- | --- | --- |
[4 lines not shown]
[docs][clang-format] Rename docs to Markdown
Rename ClangFormat and ClangFormatStyleOptions from reStructuredText to Markdown.
Update the clang-format documentation generator scripts and CMake custom targets to point at the renamed .md files so the generated documentation paths remain valid. Keep this changeset limited to rename/path updates; Markdown content cleanup is in the follow-up rewrite changeset.
[mlir-c] Destroy pattern sets in 1:N conversion tests
Same leak fix as the materialization tests on main: these tests freeze
their MlirRewritePatternSet but must still call mlirRewritePatternSetDestroy
on the (moved-from) container, otherwise LeakSanitizer flags it on the
aarch64 HWASan bootstrap bot.
[mlir][OpenACC] Preserve worker rows when combining reductions (#210804)
Example:
```fortran
!$acc parallel loop gang worker reduction(+:sum)
do j = 1, n
!$acc loop vector reduction(+:sum)
do i = 1, n
sum = sum + a(i, j)
end do
end do
```
In this code, each worker has a private partial result, but combine
predication previously allowed only ThreadY row zero to contribute.
Fix: keep ThreadY active only for proven atomic worker combines, while
preserving legacy predication or reporting NYI for unsafe combinations.
[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] 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] 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.
[MemProf] Fix memprof metadata propagation issue (#211373)
Fixes a few places where optimizations were dropping memprof related
metadata when creating new calls. Adds a new facility that can be used
to propagate profile and debug metadata, and employs that in the passes
that were manually specifying just MD_prof and MD_dbg.
[mlir-c] Fix pattern-set leak in rewrite.c materialization tests (#211358)
The `TypeConverter` materialization tests added in #208934 (`testTypeConverterSourceMaterialization` / `testTypeConverterTargetMaterialization`) freeze their `MlirRewritePatternSet` but never destroy it.
This was caught by LeakSanitizer on the aarch64 HWASan bootstrap bot ([builder 55, build
30763](https://lab.llvm.org/buildbot/#/builders/55/builds/30763)):
Fix: call `mlirRewritePatternSetDestroy(patterns)` after freezing in both tests, matching existing usage.
Assisted by: Claude
