C's Annex F specifies that atan +/-0.0 returns the input value; however, this behavior is optional and host C libraries may behave differently. This change applies the Annex F behavior to constant folding by LLVM. Ref: https://pubs.opengroup.org/onlinepubs/9799919799/functions/atan.html
ReadDataFromGlobal() did not handle reads from the padding of types (in the sense of type store size != type alloc size, rather than struct padding). Return zero in that case. Fixes https://github.com/llvm/llvm-project/issues/144279.
While there remove an unnecessary dyn_cast from Constant to Constant. Reverse a branch condition into an early out to reduce nesting.
This patch transforms: X && *X == Y to: X == Y where X is of std::optional<T>, and Y is of T or similar.
The change adds folding for 4 vector intrinsics: `interleave2`, `deinterleave2`, `vector_extract` and `vector_insert`. For the last 2 intrinsics the change does not use `ShuffleVector` fold mechanism as it's much simpler to construct result vector explicitly.
I noticed this when a sqrt produced by VectorCombine with a poison operand wasn't getting folded away to poison. Most intrinsics in general could probably be folded to poison if one of their arguments are poison too. Are there any exceptions to this we need to be aware of?
Fixes #143360
Add an optional flag to disable constant-folding for function calls. This applies to both intrinsics and libcalls. This is not necessary in most cases, so is disabled by default, but in cases that require bit-exact precision between the result from constant-folding and run-time execution, having this flag can be useful, and may help with debugging. Cases where mismatches can occur include GPU execution vs host-side folding, cross-compilation scenarios, or compilation vs execution environments with different math library versions. This applies only to calls, rather than all FP arithmetic. Methods such as fast-math-flags can be used to limit reassociation, fma-fusion etc, and basic arithmetic operations are precisely defined in IEEE 754. However, other math operations such as sqrt, sin, pow etc. represented by either libcalls or intrinsics are less well defined, and may vary more between different architectures/library implementations. As this option is not intended for most common use-cases, this patch takes the more conservative approach of disabling constant-folding even for operations like fmax, copysign, fabs etc. in order to keep the implementation simple, rather than sprinkling checks for this flag throughout. The use-cases for this option are similar to StrictFP, but it is only limited to FP call folding, rather than all FP operations, as it is about precise arithmetic results, rather than FP environment behaviours. It also can be used to when linking .bc files compiled with different StrictFP settings with llvm-link.
This is a follow up from #141845. TargetTransformInfo::getOperandInfo needs to be updated to check for undef values as otherwise a splat is considered a constant, and some RISC-V cost model tests will start adding a cost to materialize the constant.
As noted in https://github.com/llvm/llvm-project/pull/141821#issuecomment-2917328924, whilst we currently constant fold intrinsics of fixed-length vectors via their scalar counterpart, we don't do the same for scalable vectors. This handles the scalable vector case when the operands are splats. One weird snag in ConstantVector::getSplat was that it produced a undef if passed in poison, so this also contains a fix by checking for PoisonValue before UndefValue.