This is an archive of the discontinued LLVM Phabricator instance.

ValueTracking: Replace CannotBeNegativeZero
ClosedPublic

Authored by arsenm on Apr 20 2023, 4:52 PM.

Details

Summary

This is now just a wrapper around computeKnownFPClass.

Diff Detail

Event Timeline

arsenm created this revision.Apr 20 2023, 4:52 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 20 2023, 4:52 PM
arsenm requested review of this revision.Apr 20 2023, 4:52 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 20 2023, 4:52 PM
Herald added a subscriber: wdng. · View Herald Transcript
foad added a comment.Apr 21 2023, 3:02 AM

Code looks fine to me but you need to fix either the tests or the comments on them.

Code looks fine to me but you need to fix either the tests or the comments on them.

I think I’ll just defer the handling of constrained_sqrt and handle it in that patch

kpn added a comment.Apr 21 2023, 10:49 AM

Are we certain that a constrained sqrt() folded away will be as accurate as not folded when the rounding mode is different? There's a lot of permutations of library calls and instructions that constrained sqrt() can be lowered to, and I'm worried that the results will be surprisingly bad with different rounding modes. If we don't fold then the end user can deal with library issues themselves at least, and hopefully square root instructions will be on CPUs that properly handle the different rounding modes.

I'm pretty sure I wrote those comments, and I think not folding due to the rounding mode is conservatively correct. I really don't think changing this behavior belongs in a patch titled "ValueTracking: Replace CannotBeNegativeZero". Changing sqrt() folding should be a different patch.

And if constrained sqrt is folded away then the "Negative test:" comments should be removed. With the fold the comments are incorrect.

Are we certain that a constrained sqrt() folded away will be as accurate as not folded when the rounding mode is different?

I don't see how rounding can come into this. The only way to produce a -0 is a -0 source, where no rounding is involved. The exception would be for denormal flushing which isn't quite the same as rounding

foad added a comment.Jul 11 2023, 3:21 AM

Code LGTM.

It
mishandles PreserveSign denormal inputs but that's a preexisting
issue.

Mishandles? Isn't it up to the caller to worry about that?

strictfp tests are improvements. The test comment suggests these
folds should not happen, but I think are correct.

Remove this paragraph.

arsenm updated this revision to Diff 539349.Jul 11 2023, 5:20 PM
arsenm edited the summary of this revision. (Show Details)
foad accepted this revision.Jul 12 2023, 4:46 AM
This revision is now accepted and ready to land.Jul 12 2023, 4:46 AM