[llvm] r225786 - SLPVectorizer: Cache results from memory alias checking.

[Erik Eckstein]

> And what invalidates this cache? As far as I can tell the vectorizer can both delete and create new instructions, which should put this cache at risk of getting incorrect collisions.


Both, deleted and inserted instructions should not change the aliasing relationship between existing instructions. Therefore it should be OK to keep the cache alive for a whole vectorizer run on a function.

> Why should we do caching at this layer rather than in the AA layer itself?


This is a good point. My intention was: AFAIK the AA does not cause performance problems elsewhere so I put the caching in SLPVectorizer.
But I agree, it could make sense to put it into AA.


> On 13 Jan 2015, at 12:51, Chandler Carruth <chandlerc at google.com> wrote:
> 
> 
> On Tue, Jan 13, 2015 at 3:37 AM, Erik Eckstein <eeckstein at apple.com <mailto:eeckstein at apple.com>> wrote:
> Author: eeckstein
> Date: Tue Jan 13 05:37:51 2015
> New Revision: 225786
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=225786&view=rev <http://llvm.org/viewvc/llvm-project?rev=225786&view=rev>
> Log:
> SLPVectorizer: Cache results from memory alias checking.
> 
> This speeds up the dependency calculations for blocks with many load/store/call instructions.
> Beside the improved runtime, there is no functional change.
> 
> Why should we do caching at this layer rather than in the AA layer itself?
> 
> And what invalidates this cache? As far as I can tell the vectorizer can both delete and create new instructions, which should put this cache at risk of getting incorrect collisions.
> 
> I feel like this patch probably should have gone through pre-commit review. Neither this design nor why it is correct is obvious.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150113/a7221d0a/attachment.html>