This is an archive of the discontinued LLVM Phabricator instance.

ValueTrackng: Handle sign bit for fptrunc
ClosedPublic

Authored by arsenm on Apr 17 2023, 7:16 PM.

Diff Detail

Event Timeline

arsenm created this revision.Apr 17 2023, 7:16 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 17 2023, 7:16 PM
arsenm requested review of this revision.Apr 17 2023, 7:16 PM
Herald added a reviewer: sstefan1. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a subscriber: wdng. · View Herald Transcript
foad added a comment.Apr 18 2023, 2:38 AM

I feel like there are undocumented assumptions here.

Does fptrunc +/- 0.0 preserve sign?

Is Known.SignBit supposed to be accurate even for Nans? That seems unfortunate, since for a lot of operations you won't be able to propagate it unless you can prove something isn't Nan.

llvm/lib/Analysis/ValueTracking.cpp
4082

Writing this as KnownSrc.isKnownNot(NegExcept0) would make it clearer that the source and result classes are the same here.

Also why can't this logic be mirrored for PosExcept0?

I feel like there are undocumented assumptions here.

Does fptrunc +/- 0.0 preserve sign?

Yes

Is Known.SignBit supposed to be accurate even for Nans? That seems unfortunate, since for a lot of operations you won't be able to propagate it unless you can prove something isn't Nan.

That’s the only reason you need it. Otherwise you can infer from the mask. I only expect it to be useful for the few signbit operations

llvm/lib/Analysis/ValueTracking.cpp
4082

It could be but it’s more cases to test and less useful

foad added a comment.Apr 18 2023, 4:45 AM

Is Known.SignBit supposed to be accurate even for Nans? That seems unfortunate, since for a lot of operations you won't be able to propagate it unless you can prove something isn't Nan.

That’s the only reason you need it. Otherwise you can infer from the mask.

Ack. Could do with an explanatory note on the definition of SignBit.

But there's something odd here: the case in which you set SignBit in this patch is exactly the case in which you don't really need to because it could be inferred from the mask.

To put it another way, the information provided by SignBit overlaps with the mask, and each could be used to refine the other. Maybe the internal representation of KnownFPClass should be more orthogonal - you could have just a mask, but with separate bits for PosSNan NegSNan PosQNan NegQNan.

arsenm updated this revision to Diff 514605.Apr 18 2023, 4:49 AM

Move mask handling, refine nan source propagation

foad accepted this revision.Apr 26 2023, 5:34 AM
This revision is now accepted and ready to land.Apr 26 2023, 5:34 AM