This avoids a regression when SignBitMustBeZero is moved to computeKnownFPClass.
Details
Diff Detail
Event Timeline
Looks OK but shouldn't the nsz flag be applied more generally to the result of every computeKnownFPClass call?
No because of nsz’s bizarre definition. It doesn’t mean no -0 appears, it means you don’t care about the sign of zero.
This might be too strong as it is since it implies poison for -0, but I’m guessing that’s what the UseInstrInfo is for. Otherwise we would need another flag for stronger nsz interpretation
No because of nsz’s bizarre definition. It doesn’t mean no -0 appears, it means you don’t care about the sign of zero.
This might be too strong as it is since it implies poison for -0, but I’m guessing that’s what the UseInstrInfo is for. Otherwise we would need another flag for stronger nsz interpretation
I think the user intent of nsz is primarily to allow optimizations that are legal for every value except -0.0, and the use case here seems to me to be clearly that (sqrt(x) has sign=0 for every x but -0.0). It's not immediately clear to me that you can generalize handling of nsz for all cases in computeKnownFPClass.