[llvm-dev] Delinearization validity checks in DependenceAnalysis
Hubert Tong via llvm-dev
llvm-dev at lists.llvm.org
Fri May 24 15:30:53 PDT 2019
On Fri, May 24, 2019 at 3:55 PM Michael Kruse via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> [CC bollu, mferguson, shil]
> Am Do., 23. Mai 2019 um 17:13 Uhr schrieb Bardia Mahjour <
> bmahjour at ca.ibm.com>:
>> Thanks David and Michael for the clarification.
>> I think I understand the rational behind those checks in delinearization
>> > Some other languages have stronger guarantees about their array
>> dimensions accesses being in range. But this being a flat C array, there is
>> nothing out-of-bounds going on.
>> Hmm...perhaps some information about these guarantees can come from the
>> IR that the front-ends produce. I'm wondering if the 'inrange' keyword (or
>> maybe a new keyword) can be used for this purpose?
> If the source is C/C++, the inrange keyword cannot be used because of the
> language's semantics (see below).
> Also, GetElementPtr will always only work with constant-sized array. A
> student from last year's GSoC (CC'd) is working on such an extension (with
> intended use by Chapel).
> I had a discussion about this syntax with some C standard experts and
>> there seems to be disagreements on whether an out-of-bound access with
>> respect to an individual dimension is defined behaviour or not. I do not
>> mean to start that discussion here, especially because there may be code in
>> the field relying on certain interpretation of the standard, but just want
>> to mention that option-control maybe a good way to deal with complications
>> like this.
> For clarification: In C, subscripts themselves have no semantics, they are
> defined as syntactic sugar:
> C18, 220.127.116.11, §2
> > The definition of the subscript operator is that E1[E2] is identical
> Using arithmetic properties, &A == (char*)A + 2 == &A (for an
> array declared "*char* A"). The indirection operator (*) is only
> undefined if it yields to an access to an invalid address (C18, note 104).
Yes, the addresses are equal, but you make a point of talking about the
Subclause 6.5.6 says: If the result points one past the last element of the
array object, it shall not be used as the operand of a unary * operator
that is evaluated.
&A produces a result that points one past the last element of the
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev