ARM: Mark more generic libgcc functions as available
Generic libgcc/compiler-rt functions coexist with aeabi variants
(e.g., __divsi3 and __aeabi_idiv) according to my reading of the
build. At least in compiler-rt, they are aliases (such that I'm not sure
what the point of ever emitting the __aeabi name is).
They were previously removed from the available set on AEABI+AAPCS targets
to force selection of the preferred __aeabi_* variants, back when
only one implementation per libcall could be recorded.
Now that multiple implementations can be available per libcall, stop hiding
the generics and select the __aeabi_* variant explicitly as the preferred
implemntation. This reduces the number of special cases to consider for
future libcalls info improvements.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
Hexagon: Stop excluding some generic compiler-rt functions from libcalls
RuntimeLibcalls should indicate any function that exists and is callable.
Historically the list of library functions was conflated with the library
functions which should be used, so the library definition was complicated
by excluding the overridden cases. My reading of the compiler-rt sources is
that the generically named functions are built alongside the __hexagon
prefixed variants. e.g., __divsi3 and __hexagon_divsi3 both exist.
It will simplify future libcall work the fewer special case target exclusions
there are, so allow the functions to be defined and apply the selection
preference for the __hexagon prefixed versions in LibcallLoweringInfo.
I do question why compiler-rt is built this way; why doesn't the hexagon
just replace the standard entrypoint names with the target implementations?
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
MSP430: Mark more generic libgcc functions as available (#210962)
The generic soft-float, conversion, comparison and integer helper
routines (__addsf3, __divli's __divsi3, __ashlsi3, ...) exist in the MSP430
libgcc port alongside the preferred __mspabi_* variants. They were previously
removed to force selection of the __mspabi_* names, back when only one
implementation per libcall could be recorded.
Stop hiding them: only __lshrsi3 stays excluded, since the MSP430 libgcc
port provides the 32-bit logical right shift solely under __mspabi_srll and
never defines a generic __lshrsi3.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
RuntimeLibcalls: Emit all available impls for a libcall, not just one
The intent is RuntimeLibcalls should represent all functions that are
callable from the module, which may have contextually selectable alternatives.
Previously we had this warning since there was no mechanism to select which
one you want, and as a workaround the library call sets avoided adding the
variants which should nto be selected.
Now targets can use initLibcallLoweringInfo, so remove the warning to unblock
more libcall cleanups. Eventually initLibcallLoweringInfo should also be tablegen
driven.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
clang/AMDGPU: Add missing driver tests for invalid target names (#212451)
Make sure -march and -mcpu both error for nonoffload and for
-Xopenmp-target arguments. Defends against regression I almost
introduced.
[CIR] Implement non-reassoc __arithmetic_fence (#211915)
This builtin is a no-op (just a load/store) if we don't have reassociate
turned on. This patch implements the 'easy' path to unblock libraries
that use this builtin.
[CIR] Switch FlattenCFGPass to no longer use greedy manager. (#211368)
This showed up doing a self-build of MLIR's Presburger
IntegerRelation.cpp, which is a bit pathalogical. It resulted in us
doing a lot of rewrite patterns during flatten, taking about 20s. After
this patch, we're down to sub-1s spent doing that.
This is because applyOpPatternsGreedily was re-enqueing every child
opops every time we modified anything nearby. This caused us in cases
where there were operations that were visited TONS of times just because
a parent got modified.
This patch replaces this with a very simple inside-out iteration of
these operations. The recent loop-op 'cleanup' flattening modification
necessitates us re-visiting these sometimes (hence the loop).
This patch is effectively 'NFC' other than build time, so there really
isn't a test I could write.
[5 lines not shown]
[lldb] Fix flaky test_expr_with_fork_trap by increasing expression timeout (#212574)
The test evaluates an expression that forks a child which returns
normally (triggering SIGTRAP from the JIT wrapper trap at _start). The
parent blocks in waitpid() until the detached child terminates. With the
default 250ms expression timeout, the kernel sometimes doesn't schedule
the detached child fast enough, causing waitpid() to still be blocking
when the timeout fires and the expression gets interrupted.
Set a 5-second expression timeout to give the kernel ample time to
schedule the detached child process.
[CIR] Introduce fenv attribute for strict fp handling (#211144)
This introduces a new CIR attribute that will be used to describe
floating-point environment assumptions and restrictions, allowing for
general modeling of floating-point environment access. A new interface
is also introduced to simplify handling of default settings when the
attribute or one of its optional components is not present.
This patch adds the attribute and interface to FPBinaryOp,
BinaryFPToFPBuiltinOp, and UnaryFPToFPBuiltin. Support for generating
operations with this attribute and lowering them to the LLVM dialect
will be added in a future change.
Assisted-by: Cursor / claude-opus-4.8
[HLSL] Add availability attributes to texture sample methods that require implicit derivatives (#212846)
This PR adds availability attributes to texture sample methods that
require implicit derivatives (fixes
https://github.com/llvm/llvm-project/issues/198885)
To make these availability attributes actually get checked,
`DiagnoseHLSLAvailability::HandleFunctionOrMethodRef` in `SemaHLSL.cpp`
has been changed to check availability attributes regardless of whether
or not a function has a body/definition (fixes
https://github.com/llvm/llvm-project/issues/212842).
Assisted by: Claude Opus 5
[AMDGPU] Limit register pressure of pipelined loops
Opt AMDGPU into the generic MachinePipeliner register-pressure detector via
shouldLimitRegPressure(), and supply an occupancy-aware verdict in
isScheduleRegPressureTooHigh(): reject a schedule whose SGPR or VGPR/AGPR
pressure would drop the kernel below its target occupancy, or exceed a
register class's addressability cap. On gfx90a+ VGPRs and AGPRs share one
register file, so their combined footprint is bounded together. These match
the limits GCNSchedStrategy enforces.
[MachinePipeliner] Add PipelinerLoopInfo hooks to reuse the reg-pressure detector
The generic MachinePipeliner register-pressure detector (added in #74807)
was only reachable via the global -pipeliner-register-pressure flag, which
cannot be enabled per-target, and it judges pressure against generic
per-pressure-set limits. Add two PipelinerLoopInfo hooks so a target can
reuse that detector on its own terms:
- shouldLimitRegPressure(): A target can opt the loop into the detector without
the global flag.
- isScheduleRegPressureTooHigh(MaxSetPressure): let the target replace the
detector's generic per-pressure-set limit check with its own verdict, or
return nullopt to keep that check.
Both hooks default to preserving current behavior, so targets that do not
override them are unaffected.
Exercised by the AMDGPU adoption in the following commit.
[AMDGPU] Raise the MachinePipeliner MII cap via a target hook
The pipeliner rejects any loop whose minimum initiation interval (MII)
exceeds -pipeliner-max-mii, default 27. That is far too low for real
AMDGPU loops: resource-bound GEMM/attention bodies routinely have an MII
well above 27 and are dropped before scheduling even starts.
Add a PipelinerLoopInfo::getMaxMII() hook so a target can raise the cap,
and override it to 256 for AMDGPU. The generic default is unchanged, and
an explicit -pipeliner-max-mii still takes precedence.
The cap of 256 is chosen from the II distributions of two AMDGPU
workloads.
Composable Kernels:
II range count pct
0- 24 2305 36.7%
25- 49 1681 26.8%
50- 99 1582 25.3%
[13 lines not shown]
[AMDGPU] Add MachinePipeliner support for AMDGPU
Implement the target hooks to enable MachinePipeliner for AMDGPU. The
pass is off by default and can be enabled with -amdgpu-enable-pipeliner
at -O2 and above.
Only uniform, single-basic-block counted loops with a scalar (SCC)
back-edge are pipelined; loops with a divergent (VCC/EXEC) back-edge, or
containing calls or inline asm, are rejected. Code is generated by the
default modulo schedule expander (DFA, window scheduler, and MVE
expansion are disabled for AMDGPU).
Validated on gfx942 and gfx950 with Composable Kernel and Triton workloads.
[CIR] Defer indirect goto resolution to GotoSolver (#206176)
A computed `goto *p` placed inside a nested scope -- an if or a loop
body --
made CIRGen produce invalid IR that the region verifier rejected with
"reference to block defined in another region", aborting the compile.
Regular
`goto` avoids this because CIRGen emits a symbolic
`cir.goto` that references no block and is later resolved into a
`cir.br` by
GotoSolver, which runs after FlattenCFG has merged the nested scopes
into one
region. Indirect goto skipped that indirection: `emitIndirectGotoStmt`
built
a real indirect-branch block during CIRGen and branched to it from
inside the
nested region, and `finishIndirectBranch` wired the `cir.indirect_br`
successors at the end of the function -- both while the scopes were
still
[29 lines not shown]
[SBVec] Refactor BottomUpVec pass for clarity and maintainability
- Corrected comments to clarify the direction of def-use and use-def chains.
- Changed the initialization of the SchedDirection variable to improve clarity.
- Updated documentation in vectorizeRec() to better describe the purpose of UserBndl.
- Removed outdated TODO comment regarding top-down vectorization scheduling.
[SBVec] Add top-down vectorization to the unified Sandbox Vectorizer
Extend the Sandbox Vectorizer's `bottom-up-vec` pass so a single
implementation can vectorize in either direction, and add the top-down
strategy that walks def-use chains forward from a seed.
Direction selection
--------------------
The pass direction is chosen from the Region's auxiliary pass argument:
"bottom-up" (or empty, the default) and "top-down" map onto a
SchedDirection, and any other value is rejected with a fatal usage error.
The vectorizer always runs in the same direction as the scheduler.
Top-down traversal
------------------
Bottom-up starts from a seed slice (e.g. stores to consecutive addresses)
and recurses into operands. Top-down instead starts from a seed of
consecutive loads and recurses into *users*:
[32 lines not shown]
[SandboxIR] Fix notifyEraseInstr to skip scheduled neighbors
Guard both loops with !PredN->scheduled() / !SuccN->scheduled() so
scheduled neighbors are left untouched, and add a unit test that erases
a node with one scheduled and one unscheduled predecessor to cover the
fix.
[SandboxIR] Fix notifyEraseInstr to skip scheduled neighbors
Guard both loops with !PredN->scheduled() / !SuccN->scheduled() so
scheduled neighbors are left untouched, and add a unit test that erases
a node with one scheduled and one unscheduled predecessor to cover the
fix.
[HLSL] Add in-memory representation of Semantic Signatures (#209907)
Defines the `SemanticSignatureElement` struct in
`llvm/Frontend/HLSL/SemanticSignatures` to represent a semantic
signature in-memory for use during packing and metadata
construction/parsing.
Adds unit testing of the conversion.
Resolves: https://github.com/llvm/llvm-project/issues/204878
Assisted by: Claude Opus 4.8
