AMDGPU needs to know the FP mode for the function to answer this
correctly when this is removed from the subtarget
AArch64 had to make this more complicated by using this from an IR
hook, so add an IR typed overload.
arsenm on Oct 28 2019, 7:59 PM.Authored by
Is isFMAFasterThanFMulAndFAdd's MachineFunction argument currently used? Or is that coming in a follow-up Diff? I might have missed it...
D69583 starts using it (although it's still effectively a no-op until it ultimately uses a function attribute instead of a subtarget feature)
I might be missing some part of the bigger picture, but shouldn't we nail down the format of the denorm function attribute before this? It seems unnecessarily wide/vague to pass the entire MachineFunction as the param if all we care about is the 1 denorm attribute setting.
The fact that AMDGPU cares about the denormal mode context in this case is a target specific detail. It would be stranger to be passing specifically that in for every user. Another target might have more exotic constraints. AMDGPU does have other specific FP control bits that don't specifically matter here, but another target could have others that do.
Fair enough. I'd choose the other way until there was some proven need to code it this way, but that's just a matter of taste.