[LLVMdev] Vectorizing global struct pointers

[Arnold Schwaighofer]

Note that the final index(es) and size of accessed memory have to be the same, and no zero length arrays must be involved that means you have to look at the type of the gep (and I am sure I am missing other conditions here). Essentially, you have to symbolically evaluate the address computation and take the size of the access into account. Something along the lines of BasicAA::aliasGEP.

You can assume that
  %arrayidx = getelementptr inbounds %struct.anon* @Foo, i32 0, i32 1, i32 %idxprom
  %0 = load i64* %arrayidx, align 8
  %arrayidx4 = getelementptr inbounds %struct.anon* @Foo, i32 0, i32 0, i32 %idxprom
  store i64 %mul, i64* %arrayidx4, align 8
don't overlap, but not so for:
  %arrayidx = getelementptr inbounds %struct.anon* @Foo, i32 0, i32 1, i32 %idxprom
  %0 = load i64* %arrayidx, align 8
  %arrayidx4 = getelementptr inbounds %struct.anon* @Foo, i32 0, i32 0, i32 %anotheridx
  store i64 %mul, i64* %arrayidx4, align 8

On Feb 5, 2013, at 11:41 AM, Renato Golin <renato.golin at linaro.org> wrote:

> On 5 February 2013 17:28, Nadav Rotem <nrotem at apple.com> wrote:
> We insert runtime overlap checks only for unidentified objects. The problem here is that the vectorizer thinks that A,B,C are all pointers to the same array, so it gives up.  If A,B,C were different arrays then it could have used runtime checks.    
> 
> Yes, that is exactly the code that creates the run-time checks. ;)
> 
> I'll try to inspect the uses for GEPs and store the offsets in a map. If it works, we can think of a better implementation.
> 
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130205/80730ca9/attachment.html>