[clang] [llvm] Implement operand bundles for floating-point operations (PR #109798)
Serge Pavlov via cfe-commits
cfe-commits at lists.llvm.org
Mon Oct 28 08:44:04 PDT 2024
spavloff wrote:
> > Right, we would need to introduce new llvm.fadd etc. to carry bundles. If there are no bundles these could fold back to the regular instruction
>
> Good. The new intrinsics will be unknown to the optimization passes and thus be "safe by default".
Optimization passes can perform transformations based on the instruction properties rather than particular instructions. In such case constrained intrinsics can be involved in optimizations.
> > What do you mean by "safe-by-default"? Implementation must be correct, and produce the code that executes in accordance to standards and documentation. Any deviation from them is an error and should be fixed. Does it mean that such implementation would be "safe"?
>
> When I say "safe-by-default" I'm referring to the case where the optimizers don't know about the intrinsics so the optimizers get very conservative and don't optimize.
What about users who need performance? For example, running code using non-default rounding mode should demonstrate almost the same performance as in the case of default mode, if the rounding mode is changed outside this code. The only way to represent such code now is using constrained functions. If they would not be optimized, performance would be poor.
> The sticky point is the rounding mode. Running with a different rounding mode ideally wouldn't affect performance much at all, but it currently does. But fixing that requires fixing all the optimization passes.
Exactly. To fix that the constrained intrinsics should be transformed in optimizations more actively.
> I do have a ticket open to change the IRBuilder to check the function definition and set the strictfp mode automatically. But I pooched the branch on my end so I'll need to open a new ticket, hopefully this year. That still leaves hundreds of cases that need to be manually corrected.
The attribute `strictfp` requires refinement, which is outside of the proposed changes and needs to be discussed separately. In particular a function that changes FP environmet, but then restores it should not require `strictfp` environment. It means `strictfp` should not be assigned automatically.
https://github.com/llvm/llvm-project/pull/109798
More information about the cfe-commits
mailing list