This is an archive of the discontinued LLVM Phabricator instance.

[SCEV] ScalarEvolution::createSCEV(): Instruction::Or: drop completely bogus no-wrap flag detection
ClosedPublic

Authored by lebedev.ri on Jun 5 2020, 2:23 AM.

Details

Summary

That's just really wrong. I don't see why it makes sense at all.

Good thing is, it wasn't miscompiling anything, because as long as
the operands of or had no common bits set, then the add
of these operands will never overflow: http://volta.cs.utah.edu:8080/z/gmt7Sy
IOW we need no detection, we are free to just set NUW+NSW.

But as rG39e3683534c83573da5c8b70c8adfb43948f601f shows,
even when the old code failed to "deduce" flags,
we'd eventually re-deduce them somewhere, later.

So let's just set them.

Diff Detail

Event Timeline

lebedev.ri created this revision.Jun 5 2020, 2:23 AM
efriedma accepted this revision.Jun 5 2020, 1:03 PM
efriedma added a subscriber: efriedma.

If LHS is an AddRec, the result must be an AddRec because the add gets folded into the "Start". And that AddRec must have the same wrapping behavior: if it didn't, that would mean getMinTrailingZeros returned the wrong value. Therefore, setting the nowrap flags like this should be legal.

But sure, we can just specify the flags to getAddExpr itself, and let the SCEV construction code do the rest. LGTM

This revision is now accepted and ready to land.Jun 5 2020, 1:03 PM

If LHS is an AddRec, the result must be an AddRec because the add gets folded into the "Start". And that AddRec must have the same wrapping behavior: if it didn't, that would mean getMinTrailingZeros returned the wrong value. Therefore, setting the nowrap flags like this should be legal.

Ah, i see what the old code meant, thanks.

But sure, we can just specify the flags to getAddExpr itself, and let the SCEV construction code do the rest. LGTM

Thank you for the review!

This revision was automatically updated to reflect the committed changes.