This is an archive of the discontinued LLVM Phabricator instance.

[SCEV] Move SCEVLostPoisonFlags() check into SCEVExpander
ClosedPublic

Authored by nikic on Oct 24 2021, 2:45 PM.

Details

Summary

Always insert values into ExprValueMap, and instead skip using them in SCEVExpander if poison-generating flags have been lost. This ensures that all values that are in ValueExprMap are also in ExprValueMap, so we can use the latter to invalidate the former.

This change is probably not entirely NFC for the case where originally the SCEV had no nowrap flags but they were inferred later, in which case that would now allow reusing the existing value for expansion.

Diff Detail

Event Timeline

nikic created this revision.Oct 24 2021, 2:45 PM
nikic requested review of this revision.Oct 24 2021, 2:45 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 24 2021, 2:45 PM
reames accepted this revision.Oct 25 2021, 10:17 AM

So, LGTM to the code motion, but I think this code is badly incomplete.

If I understand it correctly, the intent is to prevent SCEVExpander from reusing an IR instruction with flags stronger than those implied by the SCEV. This is a laudable goal, but the code completely ignores folding of the binop during SCEV construction.

I see two correct approaches:

  1. Default to returning true (meaning can't reuse) unless we can prove flag match. This is somewhat the inverse of the current code.
  2. drop poison generating flags from the IR instruction

We could, of course, use some combination of both.

Any chance you'd be willing to follow up here? If not, I probably will.

This revision is now accepted and ready to land.Oct 25 2021, 10:17 AM

So, LGTM to the code motion, but I think this code is badly incomplete.

If I understand it correctly, the intent is to prevent SCEVExpander from reusing an IR instruction with flags stronger than those implied by the SCEV. This is a laudable goal, but the code completely ignores folding of the binop during SCEV construction.

Right. I agree that the handling is incomplete, though it might be tricky to come up with cases where it fails in practice.

I see two correct approaches:

  1. Default to returning true (meaning can't reuse) unless we can prove flag match. This is somewhat the inverse of the current code.
  2. drop poison generating flags from the IR instruction

We could, of course, use some combination of both.

Any chance you'd be willing to follow up here? If not, I probably will.

I don't plan to look into this one myself -- I only ran into this while looking at invalidation.

This revision was landed with ongoing or failed builds.Oct 25 2021, 1:37 PM
This revision was automatically updated to reflect the committed changes.