Propogation of fpclass assumptions vis a vis fast-math flags

[efriedma-quic]

@andykaylor

I think what I’d like to see is something like the current ‘nnan’ and ‘ninf’ flags, but with semantics like “allow optimizations that are unsafe in the prescence of ‘nan|inf’ but do not otherwise make assumptions about the value returned.” Or, alternatively, some way to globally control whether or not the optimizer considers fast-math flags for the purposes of value tracking, scalar evolution, etc.

See discussion on ⚙ D47963 [LangRef] nnan and ninf produce poison. . The LangRef text was changed to “poison” as part of the general effort to clarify the various meanings of “undefined” in the reference. I suggested something more conservative at the time… but I didn’t really have any examples where the “poison” behavior would cause problems. I think it makes sense to revisit if it’s causing practical issues for users.

@andykaylor

We could discuss various options within the currently available IR constructs to fix the particular case I’ve just described, but I think they mostly amount to putting obstacles in the way of the optimizer to try to prevent it from making deductions, and as such I think they’d either be susceptible to future enhancements teaching the optimizer to get past those obstacles or they would present broader optimization blocks than we would like.

The most obvious option for this is “freeze”, but there probably isn’t any way for clang to generate that without blocking a bunch of important optimizations.