[LLVM][IR] Use splat syntax when printing Constant[Data]Vector. (#112548)

[InstCombine] Remove some of the complexity-based canonicalization (#91185)

The idea behind this canonicalization is that it allows us to handle less
patterns, because we know that some will be can

[InstCombine] Remove some of the complexity-based canonicalization (#91185)

The idea behind this canonicalization is that it allows us to handle less
patterns, because we know that some will be canonicalized away. This is
indeed very useful to e.g. know that constants are always on the right.

However, this is only useful if the canonicalization is actually
reliable. This is the case for constants, but not for arguments: Moving
these to the right makes it look like the "more complex" expression is
guaranteed to be on the left, but this is not actually the case in
practice. It fails as soon as you replace the argument with another
instruction.

The end result is that it looks like things correctly work in tests,
while they actually don't. We use the "thwart complexity-based
canonicalization" trick to handle this in tests, but it's often a
challenge for new contributors to get this right, and based on the
regressions this PR originally exposed, we clearly don't get this right
in many cases.

For this reason, I think that it's better to remove this complexity
canonicalization. It will make it much easier to write tests for
commuted cases and make sure that they are handled.

show more ...

Revert "AMDGPU: Use real copysign in fast pow (#97152)"

This reverts commit d3e7c4ce7a3d7f08cea02cba8f34c590a349688b.

AMDGPU: Use real copysign in fast pow (#97152)

Previously this would introduce some codegen regressions, but
those have been avoided by simplifying demanded bits on copysign
operations.

AMDGPU: Fix vector handling in pown libcall simplification (#95832)

The isIntegerTy check would not work as you would hope in
the vector case.

Reland "[ValueTracking] Compute knownbits from known fp classes" (#92084)

This patch relands https://github.com/llvm/llvm-project/pull/86409.

I mistakenly thought that `Known.makeNegative()` clea

Reland "[ValueTracking] Compute knownbits from known fp classes" (#92084)

This patch relands https://github.com/llvm/llvm-project/pull/86409.

I mistakenly thought that `Known.makeNegative()` clears the sign bit of
`Known.Zero`. This patch fixes the assertion failure by explicitly
clearing the sign bit.

show more ...

Revert "[ValueTracking] Compute knownbits from known fp classes (#86409)"

This reverts commit d03a1a6e5838c7c2c0836d71507dfdf7840ade49.

This change caused failed assertions, see
https://github.com/

Revert "[ValueTracking] Compute knownbits from known fp classes (#86409)"

This reverts commit d03a1a6e5838c7c2c0836d71507dfdf7840ade49.

This change caused failed assertions, see
https://github.com/llvm/llvm-project/pull/86409#issuecomment-2109469845
for details.

show more ...

[ValueTracking] Compute knownbits from known fp classes (#86409)

This patch calculates knownbits from fp instructions/dominating fcmp
conditions. It will enable more optimizations with signbit idio

[ValueTracking] Compute knownbits from known fp classes (#86409)

This patch calculates knownbits from fp instructions/dominating fcmp
conditions. It will enable more optimizations with signbit idioms.

show more ...

[FPEnv][AMDGPU] Correct AMDGPUSimplifyLibCalls handling of strictfp attribute. (#86705)

The AMDGPUSimplifyLibCalls pass was lowering function calls with the
strictfp attribute to sequences that inc

[FPEnv][AMDGPU] Correct AMDGPUSimplifyLibCalls handling of strictfp attribute. (#86705)

The AMDGPUSimplifyLibCalls pass was lowering function calls with the
strictfp attribute to sequences that included function calls incorrectly
lacking the attribute. This patch corrects that.

The pass now also emits the correct constrained fp call instead of
normal FP instructions when in a function with the strictfp attribute.
Replacing non-constrained calls with constrained calls when required
is still on the IRBuilder's TODO list.

show more ...

[AMDGPU] - Add address space for strided buffers (#74471)

This is an experimental address space for strided buffers. These buffers
can have structs as elements and
a stride > 1.
These pointers al

[AMDGPU] - Add address space for strided buffers (#74471)

This is an experimental address space for strided buffers. These buffers
can have structs as elements and
a stride > 1.
These pointers allow the indexed access in units of stride, i.e., they
point at `buffer[index * stride]`.
Thus, we can use the `idxen` modifier for buffer loads.

We assign address space 9 to 192-bit buffer pointers which contain a
128-bit descriptor, a 32-bit offset and a 32-bit index. Essentially,
they are fat buffer pointers with an additional 32-bit index.

show more ...

AMDGPU: Use exp2 and log2 intrinsics directly for f16/f32

These codegen correctly but f64 doesn't. This prevents losing fast
math flags on the way to the underlying intrinsic.

https://reviews.llvm.

AMDGPU: Use exp2 and log2 intrinsics directly for f16/f32

These codegen correctly but f64 doesn't. This prevents losing fast
math flags on the way to the underlying intrinsic.

https://reviews.llvm.org/D158997

show more ...

AMDGPU: Simplify handling of constant vectors in libcalls

Also fixes not handling the partially undef case.

https://reviews.llvm.org/D158905

AMDGPU: Don't require all flags to expand fast powr

This was requiring all fast math flags, which is practically
useless. This wouldn't fire using all the standard OpenCL fast math
flags. This only

AMDGPU: Don't require all flags to expand fast powr

This was requiring all fast math flags, which is practically
useless. This wouldn't fire using all the standard OpenCL fast math
flags. This only needs afn nnan and ninf.

https://reviews.llvm.org/D158904

show more ...

AMDGPU: Add baseline tests for libcall recognition of pow/powr/pown