[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.
> 

Ah, now I think I understood what you mean: If a new instruction is allocated at the same address as a deleted instruction there is a problem.
Thanks for pointing that out! I'll fix it.

> On 13 Jan 2015, at 13:22, Erik Eckstein <eeckstein at apple.com> wrote:
> 
>> 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 <mailto: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.
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

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