[compiler-rt] Use integers for __gnu_h2f_ieee and __gnu_f2h_ieee (#220167)
In libgcc, these conversion routines use integers in the signature. In
practice compiler-rt's definition has worked because the AAPCS calling
convention passes and returns floats the same as the same-sized integer,
but this may not be the case on all platforms. Thus, update the
signatures to match GCC.
This new version calls the inlined functions directly., changing the
generated code from:
00000000 <__extendhfsf2>:
0: ee100a10 vmov r0, s0
4: e1a01000 mov r1, r0
<snip>
60: e1800001 orr r0, r0, r1
64: ee000a10 vmov s0, r0
68: e12fff1e bx lr
[28 lines not shown]
[C++20] [Modules] Profiling non dependent noexcept expression by pointer (#224528)
Another approach to solve
https://github.com/llvm/llvm-project/issues/191361 and
https://github.com/llvm/llvm-project/issues/224180 than
https://github.com/llvm/llvm-project/pull/222148
I want to avoid competing PR but I do feel the original one's approach
seems too workaround. And I want to emphasize that, in my experience,
finding the root cause is much more harder than find the solution to me.
Many thanks to @ispeters
For the approach itself, I described them in the comments of the PR.
Note that the real problem is we were profiling something is not
completely deserialized, so that even if it is not crash, the logic is
not correct.
[AMDGPU] Fold 24 bit multiply with zero low bits
Fold `MUL_I24` and `MUL_U24` to zero when either operand has known zero
low 24 bits.
For example:
```
llvm.amdgcn.mul.i24(x, 0x01000000) -> 0
```
[SelectionDAG][AMDGPU] Fold mul24 with an AND operand whose low bits are zero
Use SimplifyMultipleUseDemandedBits to simplify AND operands based on the
low 24 bits consumed by mul24.
Fold the multiply to zero when the simplified operand is zero.
This folds cases such as:
mul24(x & 0xff000000, y) -> 0
[SelectionDAG] Handle constants in SimplifyMultipleUseDemandedBits
Replace a non-zero constant with zero when none of its set bits are
demanded.
This allows users of `SimplifyMultipleUseDemandedBits` to eliminate
irrelevant constant bits while preserving the convention that a null
SDValue indicates no simplification.
[AMDGPU] Return zero LDS encoding granularity for dummy targets
Remove the redundant early return and assertion from getLDSEncodingGranule. Return zero when the target has no encoding granularity feature, and document and test the result for unknown and legacy generic targets.
Keep the existing 256-byte default in the assembly printer so compiling without a GPU still produces valid LDS sizes. Test default-target Mesa and PAL encodings and HSA metadata.
Change-Id: Ia0c69a0d7ce2858b31ee64100d37ae34bba6c42c
[AMDGPU] Add LDS encoding granularity to TargetParser
Model LDS encoding granularity with dedicated features and expose the
byte-valued getLDSEncodingGranule query for GPUKind and subarch. Keep
encoding independent of the hardware allocation granularity used for
occupancy; GFX10.3, GFX11 and GFX12.0 encode in 512-byte units while
allocating 1024-byte blocks.
Migrate program resource register and PAL metadata encoding to the new
query and remove getLdsDwGranularity from AMDGPUBaseInfo. gfx9-4-generic
uses gfx950's 1280-byte encoding granule independently of LDS capacity.
Test encoding queries, feature membership, generic-target validation and
encoded LDS sizes, including the GFX10.3 allocation/encoding distinction.
Change-Id: I9d3c2c041605e9a45fa8fbda09fc3460a74953ea
[SelectionDAG] Fix FP8 conversions to half for subnormals and overflow
Preserve subnormal values when the source format and destination have the
same exponent bias. Normalizing these inputs previously produced a
nonpositive destination exponent and an invalid floating-point encoding.
Convert finite values beyond the destination exponent range to infinity,
while preserving the existing NaN handling. This fixes Float8E5M3FNU to
half conversions that previously produced NaNs on overflow.
Add scalar and vector coverage for subnormals, signed zeros, normal
boundaries, all seven overflowing E5M3FNU encodings, and NaNs.
[InstCombine] Fold extraction of low integer bits from scalar FP
A scalar FP bitcast to an integer vector followed by extraction of its
least-significant element can use a scalar integer bitcast and truncation.
For example, extracting element zero of a float-to-<32 x i1> bitcast on a
little-endian target becomes a float-to-i32 bitcast followed by truncation
to i1. This avoids making vector legalization reconstruct an existing
scalar bit projection. A one-element vector needs only the scalar bitcast.
Extend foldBitcastExtElt for this case. Require the vector bitcast to have
one use, an integer result, and no shift after accounting for endianness.
A newly introduced source-width integer must be desirable under DataLayout
to avoid wide scalar intermediates that regress codegen. Preserve the
existing integer-source shift restrictions.
The fold reinterprets bits without FP arithmetic, preserves operand-use
count, and does not look through freeze. Update the baseline test checks.
Alive2 proof of the motivating little-endian float-to-i1 case, with poison
[2 lines not shown]
[InstCombine][NFC] Add tests for extracting integer bits from scalar FP
Add coverage for scalar FP-to-integer-vector bitcasts followed by constant
element extraction, including the float-to-<32 x i1> case. Capture existing
behavior for both endiannesses and different legal integer widths, with
one-element, multiple-use, variable-index, FP-result, poison, out-of-range,
and freeze cases.
Generate checks with the unmodified compiler. All eight RUN configurations
pass before adding the scalar FP extraction fold.
[clang][Driver] Use the bare-metal toolchain for LoongArch (#223703)
Clang did not handle loongarch32-\*-none-elf and loongarch64-\*-none-elf
in the
bare-metal toolchain, so these targets fell back to the generic ELF
toolchain,
which links by running gcc. Any -fuse-ld or --ld-path option is
forwarded to
gcc, and linking fails when there is no gcc. On a host whose gcc does
not target
LoongArch, which is the usual case when cross compiling, gcc drives the
linker
for the host, and the link fails with errors such as "a.o is
incompatible with
elf_x86_64". The generic ELF toolchain also searches /usr/local/include
and
/usr/include of the host.
The other bare-metal targets, Arm, AArch64, RISC-V, PowerPC, and x86
[12 lines not shown]
[M68k][NetBSD] Fix alignments for NetBSD/m68k. (#207602)
Linux/m68k uses the ABI from Sun Microsystems for a.out on m68k, which
aligns ints/objects/pointers/stack on 16-bit boundaries.
NetBSD/m68k on the other hand uses the ABI from SVR4 for m68k, which
aligns ints/objects/pointers/stack on 32-bit boundaries.
This is a follow-up of
https://github.com/M680x0/issues/issues/13
[CIR] Match the parameter spill shape instead of asserting it
Return null from findParamSpill when a non-byval indirect parameter's
only use is not a store into an alloca it names directly, instead of
asserting that shape. Both callers already handled a null result, so
an unmatched parameter now reaches the diagnostic the forwarding call
already has for an operand that does not name the caller's storage.
Assisted-by: Cursor / claude-opus-5
[AMDGPU] Add LDS encoding granularity to TargetParser
Model LDS encoding granularity with dedicated features and expose the
byte-valued getLDSEncodingGranule query for GPUKind and subarch. Keep
encoding independent of the hardware allocation granularity used for
occupancy; GFX10.3, GFX11 and GFX12.0 encode in 512-byte units while
allocating 1024-byte blocks.
Migrate program resource register and PAL metadata encoding to the new
query and remove getLdsDwGranularity from AMDGPUBaseInfo. gfx9-4-generic
uses gfx950's 1280-byte encoding granule independently of LDS capacity.
Test encoding queries, feature membership, generic-target validation and
encoded LDS sizes, including the GFX10.3 allocation/encoding distinction.
Change-Id: I9d3c2c041605e9a45fa8fbda09fc3460a74953ea
[AMDGPU] Return zero LDS encoding granularity for dummy targets
Remove the redundant early return and assertion from getLDSEncodingGranule. Return zero when the target has no encoding granularity feature, and document and test the result for unknown and legacy generic targets.
Keep the existing 256-byte default in the assembly printer so compiling without a GPU still produces valid LDS sizes. Test default-target Mesa and PAL encodings and HSA metadata.
Change-Id: Ia0c69a0d7ce2858b31ee64100d37ae34bba6c42c
[AMDGPU] Add partial unroll threshold function attribute (#223291)
This change adds an `amdgpu-partial-unroll-threshold` function attribute
for controlling
`TargetTransformInfo::UnrollingPreferences::PartialThreshold` on a
per-function basis.
The existing `amdgpu-unroll-threshold` function attribute initializes
`UP.Threshold`, which is used for decisions about full
unrolling. However, there is currently no corresponding AMDGPU function
attribute for configuring `UP.PartialThreshold`
independently. As a result, clients of the AMDGPU backend cannot provide
an independent per-function cost threshold for partial and runtime
unrolling.
When present, the new attribute sets the base value of
`UP.PartialThreshold` for loops in that function. This allows the cost
threshold for partial and runtime unrolling to be configured
independently of the threshold used for full unrolling. Functions that
[5 lines not shown]
[VPlan] Add VPBlockUtils::replaceSuccessor helper (NFC). (#224970)
Add a helper to redirect a single edge, keeping the successor order and
updating the predecessor links of both the old and new successor. Use it
in insertBlockBefore.
[AMDGPU] Fold fpround of fadd and fsub into v_mad/fma_mixlo and mixhi
MadFmaMixFP32Pats turns (fadd x, y) into (fma x, 1.0, y) and (fsub x, y)
into (fma (-y), 1.0, x) so the mix instructions absorb the operation along
with the f16 or bf16 source modifiers. MadFmaMixFP16Pats and
MadFmaMixFP16Pats_t16 only did this for fmul, so a rounded result still
needed a separate convert for a rounding the mix instructions perform
themselves.
Unlike the f32 patterns these do not require an operand to be an fpextend
of an f16, since an fpround on the result always removes the convert. The
rewrite is exact because the mix instructions round the f32 result again
when they write the 16-bit destination, so it stays f32_to_f16(fma(x, 1.0,
y)).
Assisted-by: Claude Code Opus 5
[AMDGPU] Require flushed FP16 denormals for the mad-mix f16 results
v_mad_mixlo_f16 and v_mad_mixhi_f16 are the unfused gfx900 forms and flush
16-bit denormals, so a denormal half result is written as zero even when the
FP16 mode asks for it to be kept, while the patterns only required the FP32
mode to flush and that is the one a HIP compile turns off on its own.
Assisted-by: Claude Code Opus 5
[NFC][AMDGPU] Add tests for fpround of fadd and fsub feeding the mix instructions (#224909)
The f32 mix patterns already fold fadd and fsub into v_mad_mix_f32 and
v_fma_mix_f32, but the f16 and bf16 forms only fold fmul, so a half or
bfloat result still pays for a separate convert.
Also cover the denormal modes an f16 result depends on and an f16
source feeding an f16 or bf16 mix. The existing mad-mix-lo and
mad-mix-hi functions now flush denormals for every type rather than
for f32 alone.
Assisted-by: Claude Code Opus 5
