[PATCH] Allow global structures to be vectorized

[Arnold Schwaighofer]

If you want to use Alias analysis see MemoryDependenceAnalysis::getDependency(Instruction *QueryInst) for an example how-to query AA if two accesses might alias. In principle,  you query AA->getLocation(Inst) to obtain the location (ignoring special cases). You then use this info to query AA->alias(Loc1, Loc2).

You might be able to just use MemoryDependenceAnalysis.

I am not sure the cases we would catch justify the added cost. This would have to be evaluated.

- Arnold

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

> Hi Arnold,
> 
> Thanks for the review. Please note that the patch is not ready, I'm looking for ideas... not final code review. ;)
> 
> 
> On 6 February 2013 17:03, Arnold Schwaighofer <aschwaighofer at apple.com> wrote:
> I don't think this is correct. You are asserting that: "Two geps will only alias if they have the same elements in the index list"?
> 
> I *know* it's not correct. I should have been a bit more clear about that in my first email... ;)
> 
> I haven't put in proper alias analysis yet, just trying to see if the skeleton of the code makes sense. Ignore the checks and alias analysis, for now...
> 
> My plan is to add the AA steps directly on the WriteObjects values, but I don't know at which level it'd be more effective (instruction, or underlying value). If I do at the value level, I lose the instruction and thus the GEP info. If I do at the instruction level, I can't match reads against writes.
> 
> My question for this iteration is: To make it easier for the Alias Analysis (which I still don't know how to do but am guessing something to do with AliasAnalysis::alias(Loc, Loc)), what should I keep in the Set?
> 
> I could keep the Location of each access, so that on the read part, I'd just ask:
> 
>   if (AliasAnalysis::alias(PrevWriteLoc, ThisReadLoc))) { BAD! }
> 
> Would that take care of all cases? Would that be sensible?
> 
> cheers,
> --renato

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