This is extracted/simplified from D45710 because I think we should break that into smaller pieces and have tests for each step. If nobody else thinks that's necessary, I'll abandon.
Note that I'm proposing that we go without adding an 'isFast()' umbrella in the DAG to avoid that misuse entirely. This means that the relatively few current folds that use SDNodeFlags may have bugs where we are overstepping the bounds of 'reassoc' alone.
But that's ok because these folds are also checking TargetOptions.UnsafeFPMath which isn't actually an umbrella flag based on its code comment:
/// UnsafeFPMath - This flag is enabled when the /// -enable-unsafe-fp-math flag is specified on the command line. When /// this flag is off (the default), the code generator is not allowed to /// produce results that are "less precise" than IEEE allows. This includes /// use of X86 instructions like FSIN and FCOS instead of libcalls.
I think this is intended to have the same meaning as 'reassoc' in IR:
reassoc Allow reassociation transformations for floating-point instructions. This may dramatically change results in floating-point.
So this flag can be set independently of NoSignedZerosFPMath for example, and we're supposed to be restricting folds based on that possibility. If not, then we already have a bug (most likely with handling of -0.0).
To fix that, we need to audit each transform (as we've been doing in IR) to see exactly which FMF are required for each transform.
So in summary, this patch is intended to be no more wrong than we already may be. It just seeks to unify the flags between IR and the DAG.