[Attr] Add `noipa` function attribute (#203304)
This adds a `noipa` function attribute to LLVM IR. This new attribute
disables any interprocedural analysis that inspects the definition of
the function. Setting this attribute is equivalent to moving the
function definition to a separate, optimizer-opaque, module.
The `noipa` attribute does *not* control inlining or outlining. Add the
`noinline` and `nooutline` attributes as well in cases where inlining
and outlining should additionally be disabled.
Revival of https://reviews.llvm.org/D101011
Discussed in https://discourse.llvm.org/t/noipa-continues/74411
LLVM portion of https://github.com/llvm/llvm-project/issues/40819
[clangd] Fix unknown doxygen command parsing in parameter documentation (#202121)
This patch mainly fixes a bug with parsing of unknown doxygen commands
in function parameter documentation.
To extract the parameter documentation from the function documentation,
the whole function documentation is parsed first.
Then the documentation paragraph for the requested parameter is
"converted" to a string and stored as the documentation for the
parameter. The string is converted by visiting and dumping all chunks of
the parsed paragraph.
When unknown doxygen commands are parsed (during the function
documentation parsing step), they are registered in a
`clang::comments::CommandTraits` object.
Visiting the unknown command requires to query the registered commands
through the `clang::comments::CommandTraits` object to get the command
name.
[18 lines not shown]
[MLIR][WASM] Re-Introduce the RaiseWasmMLIRPass to convert WasmSSA MLIR to core dialects (#205483)
See the previous PR here:
https://github.com/llvm/llvm-project/pull/164562
It was reverted by @lforg37 because of some build bot issue: see
https://github.com/llvm/llvm-project/pull/164562#issuecomment-4756828598.
However, after checking on my end, I could not reproduce the buildbot
issue. Seeing that the problem triggered in `flang` which is completely
unrelated to this work, I assume that it was a builder or a flaky test
problem so I'm re-opening this PR as it had been initially merged.
---------
Signed-off-by: Ferdinand Lemaire <flemairen6 at gmail.com>
Co-authored-by: Ferdinand Lemaire <ferdinand.lemaire at woven-planet.global>
Co-authored-by: Ferdinand Lemaire <flemairen6 at gmail.com>
utils/AMDGPU: Add scripts to update tests using default subtarget
Add vibe coded scripts to migrate AMDGPU codegen tests that run llc
without a -mcpu argument. This should either be uncommitted or delete
after the migration is completed.
amdgpu-pin-default-subtarget.py adds an explicit -mcpu matching the current
default for the triple's OS (amdhsa defaults to gfx700, all others to
gfx600). The blank default subtarget is a featureless generic that does not
match any explicit -mcpu, so pinning changes codegen; the batch driver
amdgpu-pin-default-subtarget-batch.sh regenerates the autogenerated CHECK
lines and reverts anything that still fails.
Co-Authored-By: Claude <noreply at anthropic.com> (Claude-Opus-4.8)
clang: Move __builtin_amdgcn_processor_is diagnostic test to sema (#205734)
This wasn't checking the codegen result, so move it to the right place
and use -verify instead of FileChecking stderr.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
[Support][CHERI] Refactor CHERICapabilityFormatBase to embrace CRTP (#205623)
Currently CHERICapabilityFormatBase does not provide a definition for
getAlignmentMask, but does provide a declaration, which leads to
warnings when building with MSVC. We want to have an abstract base here
without any dynamic dispatch, which is what CRTP is for, so use it for
getAlignmentMask such that the base can provide a definition that uses
each derived type's implementation, just as the two base wrappers were
already doing when calling getAlignmentMask. Whilst doing this we might
as well move the wrappers to the header so they can be inlined (and now
that getAlignmentMask is defined we can use it in the helpers rather
than needing each of them to explicitly use the derived type).
Fixes: 7dc09d0d3cf1 ("[CHERI] Add a Support utility for determining
alignment requirements of CHERI capabilities. (#197402)")
AMDGPU: Avoid default subtarget in codegen tests (4/9)
Continue migrating targets away from codegenning the dummy target
by script.
Co-Authored-By: Claude <noreply at anthropic.com> (Claude-Opus-4.8)
AMDGPU: Avoid default subtarget in hand-written codegen tests (8/9)
Introduce the missing -mcpu argument to some tests which are not
autogenerated.
Co-Authored-By: Claude <noreply at anthropic.com> (Claude-Opus-4.8)
AMDGPU: Avoid default subtarget in hand-written codegen tests (6/9)
Introduce -mcpu arguments in tests which didn't require check line
updates.
Co-Authored-By: Claude <noreply at anthropic.com> (Claude-Opus-4.8)
AMDGPU: Avoid default subtarget in hand-written codegen tests (9/9)
Fix some manual test checks using amdgcn triples without -mcpu. These require the
most careful consideration. The highest impact changes are the optimizations
removing execz branch now that there's a sched model.
AMDGPU: Avoid default subtarget in hand-written codegen tests (7/9)
Introduce an -mcpu argument to tests missing it to avoid codegening
the default dummy target. These are cases that didn't require adjusting
the check lines.
Co-Authored-By: Claude <noreply at anthropic.com> (Claude-Opus-4.8)
AMDGPU: Avoid default subtarget in hand-written codegen tests (5/9)
Introduce -mcpu arguments in tests that did not need check line updates.
Co-Authored-By: Claude <noreply at anthropic.com> (Claude-Opus-4.8)
AMDGPU: Avoid default subtarget in generated codegen tests (3/9)
Another batch of tests updated by script.
Co-Authored-By: Claude <noreply at anthropic.com> (Claude-Opus-4.8)
AMDGPU: Avoid using default subtarget in generated codegen tests (1/9)
Fix codegen tests using amdgcn triples without a target-cpu. The dummy
default subtarget has always been an irritating edge case to deal with.
For unknown/mesa3d/amdpal triples, this has been a gfx600-like result
and gfx700-like result for amdhsa. Convert tests to use the explicit
target. This was performed by vibe-coded script, and covers tests
using update_{llc|mir}_test_checks. There are some minor codegen differences
to be expected, mostly due to now having a scheduling model.
In the future we should forbid trying to codegen the default target.
Co-Authored-By: Claude <noreply at anthropic.com> (Claude-Opus-4.8)
AMDGPU: Avoid default subtarget in generated codegen tests (2/9)
Continue migrating away from testing the dummy target, and use
real targets approximating the old behavior. Performed by script.
Co-Authored-By: Claude <noreply at anthropic.com> (Claude-Opus-4.8)
[LifetimeSafety] Fix loop liveness leakage for conditional operator
Generate flow facts for conditional operators in their respective
predecessor blocks (branches) instead of the merge block, path-isolating
the flows and preventing liveness from leaking across loop backedges.
Also includes tests, formatting cleanups, and refactoring of the flow propagation.
TAG=agy
CONV=b4614911-a1e1-489f-a395-2f895c423788
Reapply "[InstCombine] Merge consecutive assumes", round 2 (#205773)
This patch was reverted due to triggering another bug. That bug has been
fixed by https://github.com/llvm/llvm-project/pull/205275, so this
should be ready to land now.
Original commit message:
This should make assumes a bit more efficient, since it removes a few
instructions. This should also help with optimizations that are limited
in how many instructions they step through.
This reverts commit 053d75c1d580e0c394f4cfb0688bafd05c187b0f.
[X86] Select BLSMSK for i8 operands (#205093)
Adds a tablegen pattern to select BLSMSK i8 for
```
%neg = sub i8 %x, 1
%and = xor i8 %neg, %x
```
I've used Claude to generate the comment line before the tablegen entry and the ll file decoding which I confirmed after llc
Fixes #204984
[LifetimeSafety] Fix loop liveness leakage for conditional operator
Generate flow facts for conditional operators in their respective
predecessor blocks (branches) instead of the merge block, path-isolating
the flows and preventing liveness from leaking across loop backedges.
Also includes tests, formatting cleanups, and refactoring of the flow propagation.
TAG=agy
CONV=b4614911-a1e1-489f-a395-2f895c423788
[X86] Fold splat XOR on VGF2P8AFFINEQB source (#204508)
Given that XORs are associative, a XOR on `vgf2p8affineqb`'s source can
be reassociated to occur after by first permuting by the matrix. If the
XOR operand is a 8-bit splat, it can be applied for free by combining it
with the immediate. This patch:
- Folds XOR by splat on `vgf2p8affineqb`'s source into its immediate.
- Only occurs when the matrix is both constant and splat across each
64-bit lane.
- Can occur when the XOR is multi-use, as it can still reduce the
dependency chain.
- Includes test coverage for a variety of matrices and negative cases
for when the fold isn't possible.
Fixes #179606
[Flang][OpenMP] Add combined construct information (#198783)
This patch adds the `omp.combined` attribute to OpenMP dialect
operations following changes to the `ComposableOpInterface`.
This attribute is added to operations representing non-innermost leaf
constructs of a combined construct and to standalone block-associated
constructs that can be combined with their parent construct.
Changes are made to the OpenMP lowering logic, as well as the
do-concurrent, workshare and workdistribute transformation passes.
[MLIR][OpenMP] Explicit tagging of combined constructs (#198782)
Combined OpenMP constructs, such as `parallel do`, which represent nests
of constructs where each one contains a single other construct without
any other directives or statements in between, are currently not marked
in any way in the MLIR representation.
This works because they don't usually require any specific handling
other than what would be done for the included operations. However, the
handling of `target` regions needs to know whether it was part of a
combined construct in order to properly optimize for the SPMD case and
detect when certain clauses must be inconditionally evaluated in the
host.
So far, this has been achieved by having some MLIR pattern-matching
logic to infer whether a nest of operations could have potentially been
produced for a combined construct. This approach is error prone,
computationally expensive and it can't really work in the general case.
On the other hand, a compiler frontend can easily tell the difference
[10 lines not shown]
[Flang][MLIR][OpenMP] Explicitly represent omp.target kernel types (#186166)
Currently, the kernel type (i.e. `generic`, `spmd`, `spmd-no-loop` and
`bare`) of an `omp.target` operation is not an explicit attribute of the
operation. Rather, this is inferred based on the contents of its region
and clauses.
The problems with this approach are that it can be a potentially
resource intensive check for large kernels, and misidentifications are
prone to happen based on the presence of arbitrary operations from other
dialects.
Since the AST already contains the information needed to identify the
kernel type in a more reliable manner, this patch moves that
responsiblity to the Flang frontend. Other MLIR passes that create
`omp.target` operations are updated as well.
One known limitation of this approach is that the MLIR op verifier for
`omp.target` can't completely check that the contents of its region are
[4 lines not shown]
