[llvm] [InstCombine] Fold more 'fcmp' 'select' instrs idioms into 'fabs' (PR #83381)

Joshua Cranmer via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 26 13:09:36 PDT 2024


jcranmer-intel wrote:

>        a) missing phi node from frontend: For 'nofabs', why are we not getting the phi node as we are getting it for 'fabs'? Modifying clang to generate phi node for 'nofabs' may solve this particular issue.

I'm not an expert in codegen, but I'm guessing because the ternary operator returns a value, it needs to insert a `phi` to lower the ternary operator correctly, whereas the non-ternary-case is going through variables, which all starts out as `alloca`s.

>        b) fast math attributes on select/phi instructions: For the 'fabs', front end is probably deducing the fast math attribute from the fast-math flag and already setting it for phi node. In this sense, it wont be inappropriate to set the fast-math flags on the select instruction in 'nofabs' somehow.

The broader point here is that when the frontend is generating the PHI nodes, it knows what flags it can set on the operations. But when it is being done by an optimization pass, that knowledge is lost.

>     2. Deducing fast-math attributes on the all the instructions just before inlining:
>        Why not do this similar to 1(b) above and as @nikic might be suggesting?

I don't like the function-based fast-math attributes... but it does seem to be the only quick path out of here.

>     3. Fast-math attributes on the function parameters:
>        Is there  documentation somewhere that says if you have fast-math flag enabled at frontend, the fast-math attributes apply to function paramters as well? Also, having `nzero` on function parameter would disallow passing -0.0 as the function argument as the lang reference says:

`nsz` is by no means equivalent to `nofpclass(nzero)`: in the former case, `-0.0` is treated as equivalent to `+0.0`; in the latter case, `-0.0` is treated as poison, aka, "do whatever you like".

https://github.com/llvm/llvm-project/pull/83381


More information about the llvm-commits mailing list