[llvm-dev] LSR/SCEV problem/question

[Geoff Berry via llvm-dev]

Hi All,

 

I've run into what appears to be a bug in ScalarEvolution, but I'm not sure
if it is instead caused by me missing an implicit assumption between LSR and
SCEV.

This issue is caused by the change D18001 <http://reviews.llvm.org/D18001> ,
which is an attempt to increase SCEV-inserted instruction re-use by picking
a more canonical insertion position in the case where a new insert position
block is not found.

The problem I have run into with this change is that it causes an insert
position instruction to be chosen which is later hoisted into a different
block by  SCEVExpander::hoistIVInc().  This in turn makes the SCEVExpander
Builder InsertPt inconsistent (the instruction and block end up not
matching), which leads to an invalid instruction being inserted (with its
parent != its containing block).

 

Does anyone more familiar with the design of the LSR/SCEV interaction have
an opinion on what the right approach to fixing this is?  The two approaches
I've considered are: 1) avoid choosing an insert point that SCEV will move
or 2) make SCEVExpander handle the case where it moves an instruction that
is an insert point.  I've attempted (2), but it gets ugly pretty fast since
there are quite a few different insert points and builders saved/restored.
(1) also seems tricky, since it essentially means LSR will have to predict
what SCEVExpander is going to do and work around this case.

 

Any thoughts would be most appreciated,

 

--

Geoff Berry

Employee of Qualcomm Innovation Center, Inc.

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160323/8a4d759d/attachment.html>