clang already emits this with -cl-no-signed-zeros, but codegen
doesn't do anything with it. Treat it like the other fast math
attributes, and change one place to use it.
Details
- Reviewers
• tstellarAMD echristo jlebar
Diff Detail
Event Timeline
include/llvm/Target/TargetOptions.h | ||
---|---|---|
161 | "when the -foo flag is specified" or "when -foo is specified" | |
lib/Target/TargetMachine.cpp | ||
91 | Personally I'd prefer to do this in a separate patch, and to make a reasonable attempt at updating our documentation to say that this implies the others. It was only after working on these flags for a few weeks that I even realized that UnsafeFPMath implies the others in IR (and therefore that it should imply the others elsewhere). I even went as far as to add a separate unsafe-fp-math flag to XLA separate from the fast-math flag. Oops. :) | |
test/CodeGen/AMDGPU/fsub.ll | ||
115 | Can we add a (brief ok) comment explaining why this one gets an xor but the others don't? |
lib/Target/TargetMachine.cpp | ||
---|---|---|
91 | Oh, I see why you're doing it here -- you don't want to regress existing codegen that sets UnsafeFPMath but not this flag (which is new). I guess you have to do it this way. We should still do this with the intent to update the docs and set the other flags, though. |
lib/Target/TargetMachine.cpp | ||
---|---|---|
91 | I would actually prefer to someday split unsafe math into an unsafe algebra flag which does not imply the others for places where you can reassociate without changing nan/inf behavior. Oddly, I checked what clang does for just -funsafe-math-optimizations. It sets unsurprisingly: But I was surprised it still emits: but these are enabled by -ffast-math. So from a practical point of view in the current world it doesn't really need to imply it, but it also confuses me about what unsafe-fp-math is really supposed to mean if before it was a stand in for no-signed-zeros. |
lib/Target/TargetMachine.cpp | ||
---|---|---|
91 |
I mean, me too. At least, I *think* I want to be able to reassociate / lose precision without assuming that I never produce a NaN or Inf. I *think* that's rather useful, but maybe someone can learn me why it's not. And clearly the flags are a mess, yikes. But at an IR level, the only way to set "unsafe-fp-math" on an instruction is with the "fast" attr, and that implies all the the things. I'm also not a fan of pretending that we have more configurability than we actually do... |
Don't have unsafe-fp-math imply no-signed-zeros. Surprisingly only one other test failed besides the ones I was editing in the first place for this
"when the -foo flag is specified" or "when -foo is specified"