This is an archive of the discontinued LLVM Phabricator instance.

DAG: Recognize no-signed-zeros-fp-math attribute
ClosedPublic

Authored by arsenm on Jan 18 2017, 5:22 PM.

Details

Summary

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.

Diff Detail

Event Timeline

arsenm created this revision.Jan 18 2017, 5:22 PM
kzhuravl added inline comments.Jan 18 2017, 9:43 PM
include/llvm/Target/TargetOptions.h
163

rezo->zero.

lib/CodeGen/SelectionDAG/DAGCombiner.cpp
632

line exceeds 80 chars.

lib/Target/TargetMachine.cpp
81

This line duplicates the previous one.

arsenm updated this revision to Diff 84931.Jan 18 2017, 9:53 PM
arsenm marked 3 inline comments as done.

Address feedback

echristo edited edge metadata.

Justin has been looking at these things lately.

jlebar added inline comments.Jan 24 2017, 6:20 PM
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?

jlebar added inline comments.Jan 24 2017, 6:23 PM
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.

arsenm marked an inline comment as done.Jan 24 2017, 9:55 PM
arsenm added inline comments.
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:
"unsafe-fp-math"="true"
"no-signed-zeros-fp-math"="true"
"no-trapping-math"="true"

But I was surprised it still emits:
"less-precise-fpmad"="false"
"no-infs-fp-math"="false"
"no-nans-fp-math"="false"

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.

jlebar added inline comments.Jan 24 2017, 9:59 PM
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.

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...

arsenm updated this revision to Diff 85695.EditedJan 24 2017, 10:01 PM

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

jlebar accepted this revision.Jan 24 2017, 10:05 PM

lgtm with the other outstanding comments addressed.

This revision is now accepted and ready to land.Jan 24 2017, 10:05 PM
arsenm closed this revision.Jan 24 2017, 10:20 PM

r293024