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

[Joshua Cranmer via llvm-commits]

jcranmer-intel wrote:

> Second, considering above comment, the line of action is unclear. Consider the SROA output [here](https://godbolt.org/z/MW1z5ecPe) and as can be seen, one of the operands to phi is the function arg. It becomes imperative to have fast-math flags on the func argument and this does not serve the purpose when phi argument is local/global instead of func arg. Could you please elaborate here?

The function-level attributes essentially assert that the entire body of the function was compiled with the `nsz` flag, and thus it would be legal for SROA to add `nsz` to the phi's it generates. It's not about where the phi arguments come from, it's that the phi lives in a function where all code in that function should have the appropriate flag applied to it. (Consequently, when inlining, it's necessary to disable the flag when you inline a function without this attribute into one that has it, but we already do that).

> First, its still unclear to me why it is not appropriate to deduce fast-math flags from the func attributes in InstCombine and why that should be done in SROA.

Reliance on the function-level attributes should probably be minimized as a general concern. As a more practical matter, virtually none of the existing checks for FMF think to check the function-level attributes, and it would be more work to fix all of the existing FMF checks rather than having some pass propagate function-level attributes to the individual instructions that are checked.

In this particular case, we already know that the phis lacking the necessary FMF are coming from SROA, and so it's reasonable to make SROA responsible for propagating function-level attributes to the phis it generates.

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