This is an archive of the discontinued LLVM Phabricator instance.

[IndVars] Fix usage of SCEVExpander to not mess with SCEVConstant. PR38674
ClosedPublic

Authored by mkazantsev on Aug 27 2018, 12:44 AM.

Details

Summary

This patch removes the function expandSCEVIfNeeded which behaves not as
it was intended. This function tries to make a lookup for exact existing expansion
and only goes to normal expansion via expandCodeFor if this lookup hasn't found
anything. As a result of this, if some instruction above the loop has a SCEVConstant
SCEV, this logic will return this instruction when asked for this SCEVConstant rather
than return a constant value. This is both non-profitable and in some cases leads to
breach of LCSSA form (as in PR38674).

Whether or not it is possible to break LCSSA with this algorithm and with some
non-constant SCEVs is still in question, this is still being investigated. I wasn't
able to construct such a test so far, so maybe this situation is impossible. If it is,
it will go as a separate fix.

Rather than do it, it is always correct to just invoke expandCodeFor unconditionally:
it behaves smarter about insertion points, and as side effect of this it will choose a
constant value for SCEVConstants. For other SCEVs it may end up finding a better insertion
point. So it should not be worse in any case.

NOTE: So far the only known case for which this transform may break LCSSA is mapping of SCEVConstant to an instruction. However there is a suspicion that the entire algorithm can compromise LCSSA form for other cases as well (yet not proved).

Diff Detail

Event Timeline

mkazantsev created this revision.Aug 27 2018, 12:44 AM
mkazantsev retitled this revision from [IndVars] Fix usage of SCEVExpander in IndVarSimplify to not mess with SCEVConstant. PR38674 to [IndVars] Fix usage of SCEVExpander to not mess with SCEVConstant. PR38674.Aug 27 2018, 12:57 AM
uabelho resigned from this revision.Aug 27 2018, 2:15 AM

This indeed solves the problem I reported in PR38674 but I don't know IndVarSimplify enough to say if this is the right solution or not.

Thanks!

mkazantsev edited the summary of this revision. (Show Details)Aug 27 2018, 2:52 AM
greened added inline comments.Aug 29 2018, 6:39 AM
test/Transforms/IndVarSimplify/pr38674.ll
103

Is it really necessary to check all of the generated IR like this? Could the test be written to only check the instructions participating in the LCSSA value flow? If so, it would make the test more robust.

LGTM in general.

So by removing expandSCEVIfNeeded, we now rely on gvn to eliminate the redundant code.

Maybe we could explain in the commit message:
Is mapping SCEVConstant to Instruction the only problem of expandSCEVIfNeeded?
Is it possible to fix the problem by directly codegening the constant from SCEVConstant in expandSCEVIfNeeded?

mkazantsev added a comment.EditedSep 3 2018, 8:21 PM

So by removing expandSCEVIfNeeded, we now rely on gvn to eliminate the redundant code.

I don't think that anything will change in this perspective. expandCodeFor also makes this lookup, so if the map contains an existing value it will reuse it. It just behaves smarter about expansion points, constants etc.

Is mapping SCEVConstant to Instruction the only problem of expandSCEVIfNeeded?

It's the only case for which I have prove. The correctness of entire algorithm is under suspicion, I am currently investigating it.

Is it possible to fix the problem by directly codegening the constant from SCEVConstant in expandSCEVIfNeeded?

What's the point of that? I generally don't see any profit in going manually into rewriting internals and trying to find something in its map. Expand methods are designed to handle such cases.

mkazantsev added a comment.EditedSep 3 2018, 8:30 PM
test/Transforms/IndVarSimplify/pr38674.ll
103

I'm having a crawling suspicion that this algorithm is generally wrong in terms of preserving SSA form. I would rather keep the tests verbose as possible just to make sure that we don't break it anyhow else.

mkazantsev edited the summary of this revision. (Show Details)Sep 3 2018, 8:37 PM
mkazantsev edited the summary of this revision. (Show Details)Sep 3 2018, 8:43 PM
This revision was not accepted when it landed; it landed in state Needs Review.Sep 3 2018, 10:02 PM
This revision was automatically updated to reflect the committed changes.