[llvm] r184684 - LoopVectorize: Add utility class for checking dependency among accesses

[Preston Briggs]

Hi Chandler,

I attempted to address your concerns back in October/November. I may not
have gotten it right, but I certainly didn't ignore your input. If you look
at the section starting at line 3244 in DependenceAnalysis.cpp, you'll see
that I try to take advantage of GEPs if they exist and if they are the same
type. If they don't or aren't, then I fall back and use the SCEVs directly.

I'll have to read the rest of Arnold's email carefully.

Thanks,
Preston




On Mon, Jul 1, 2013 at 11:24 AM, Chandler Carruth <chandlerc at google.com>wrote:

> Just FYI,
>
> On Mon, Jul 1, 2013 at 11:18 AM, Arnold Schwaighofer <
> aschwaighofer at apple.com> wrote:
>
>> - Using GetElementPtr during the analysis.
>>
>>   Part of the current analysis depends on two geps with matching pointer
>> types. I don’t think this is the right approach. Two differently typed
>> GetElementPtr’s can compute the same access function. The GetElementPtr is
>> only a way to describe address computation. GetElementPtrs don’t impose
>> interesting constraints (see my next point) that would not be embodied by
>> the ScalarEvolution of the pointer. But the ScalarEvolution is in a
>> canonical form and therefore we would not need to dependent on matching gep
>> pointer types.
>>   I believe the analysis should directly work from and directly interpret
>> the ScalarEvolution function describing the access function.
>>
>
> This has come up before. I made similar comments a long time ago about the
> dependence analysis pass. I really think that it is using GEPs as though
> they were SCEV descriptions of a pointer, and would be substantially better
> to implement (as you describe) in terms of SCEVs directly.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130701/b794c140/attachment.html>