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

[Preston Briggs]

Testing makes sense, especially in the troublesome cases of:

   -  multi-dimensional arrays where some of the dimensions are specified
   by parameters, and
   -  out-of-range indices.

Preston



On Fri, Jul 19, 2013 at 10:19 AM, Tobias Grosser <grosser at google.com> wrote:

> I suggested to rewrite this with SCEV. However, other people, e.g.
> Sebastian, commented that such a rewrite may not be necessary or could in
> fact be performed in-tree if shown to be necessary. I personally would also
> be OK with committing this code in tree and then improving it as we go. The
> code itself looked good and worked as advertised. What we now need is
> probably more experience with that kind of analysis. Having this in tree
> and possibly hooking up some (experimental) users may help us to get this
> experience.
>
> Tobi
>
>
> On Thu, Jul 18, 2013 at 10:40 AM, Hal Finkel <hfinkel at anl.gov> wrote:
>
>> ----- Original Message -----
>> >
>> >
>> > In fact Hal posted a delinearization pass some time ago (I do not
>> > have the email at hand). It did a pretty good job.
>>
>> Yea ;) -- As I recall, it also needed a rewrite because it built up its
>> internal expression tree from the instruction stream instead of reusing the
>> expression tree from the SCEVs. The underlying algorithm, however, did seem
>> to work pretty well.
>>
>>  -Hal
>>
>> >
>> >
>> >
>> > Cheers,
>> > Tobi
>> >
>> >
>> >
>> > On Wed, Jul 17, 2013 at 5:48 PM, Andrew Trick < atrick at apple.com >
>> > wrote:
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Jul 1, 2013, at 6:14 PM, Chandler Carruth < chandlerc at google.com >
>> > wrote:
>> >
>> >
>> >
>> > If we want to define an IR construct to express multidimensional
>> > array references without linearizing, I suspect we would need a very
>> > different / new instruction... retrofitting GEP seems risky given
>> > its existing uses and complexity. If you or other folks have ideas
>> > of how to represent this effectively in LLVM's IR, by all means fire
>> > away. =]
>> >
>> >
>> >
>> >
>> > Personally, I think it would be useful to at see if we could at least
>> > delinearize "obvious" or "easy" cases. We might actually get
>> > reasonably good mileage out of this. However, my perspective here is
>> > biased -- I work almost exclusively with a language that doesn't
>> > provide the guarantees Fortran does regarding multidimensional
>> > arrays.
>> >
>> > Agreed. We should find out which important cases cannot be
>> > successfully delinearized without further IR annotation and only
>> > then think about extending IR.
>> >
>> >
>> > -Andy
>> > _______________________________________________
>> > llvm-commits mailing list
>> > llvm-commits at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> >
>> >
>> >
>> > _______________________________________________
>> > llvm-commits mailing list
>> > llvm-commits at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> >
>>
>> --
>> Hal Finkel
>> Assistant Computational Scientist
>> Leadership Computing Facility
>> Argonne National Laboratory
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130719/b763f580/attachment.html>