[llvm-dev] LSR/SCEV problem/question

[Geoff Berry via llvm-dev]

Hi Michael,

 

I neglected to mention one other important detail.  The larger goal I’m working towards is getting loop invariant outputs sunk outside of loops after LSR.  Without doing the sinking, this shortcoming in LSR/SCEV often gets fixed by later passes (e.g. ISel) combining the redundant instructions when they are in the same block.  This isn’t always the case though, as I do see some scattered code improvements with the original patch in isolation.

 

It seems like it might be possible to move all of the insertion point calculation into SCEV since LSR doesn’t seem to use the insert point other than calculating the initial value and then passing it in/out of Rewriter.exandCodeFor(), though I would appreciate hearing from someone more experienced in the interaction between these two passes before going that route.

 

 

--

Geoff Berry

Employee of Qualcomm Innovation Center, Inc.

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

 

From: mzolotukhin at apple.com [mailto:mzolotukhin at apple.com] 
Sent: Wednesday, March 23, 2016 3:05 PM
To: Geoff Berry <gberry at codeaurora.org>
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] LSR/SCEV problem/question

 

Hi Geoff,

 

How was it handled before your change? Were we just lucky that insert points always matched?

 

Would it be possible to move all the logic for finding a proper insertion into SCEVExpander? I think that is ultimately the best solution for this, but I have to admit I looked into this code a while ago.

 

Michael

 

On Mar 23, 2016, at 9:22 AM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > wrote:

 

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  <http://reviews.llvm.org/D18001> 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

 

_______________________________________________
LLVM Developers mailing list
 <mailto:llvm-dev at lists.llvm.org> llvm-dev at lists.llvm.org
 <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160324/e787d566/attachment-0001.html>