<div dir="ltr">Hello,<div><br></div><div>After <a href="http://pollylabs.org/gsoc2018/Compiling-Chapel-with-Polly-and-LLVM.html">Sahil's GSoC 2018 project on integrating Chapel into Polly</a>, and running into similar issues with delinearization multiple times before, we began drafting up an RFC to introduce these kinds of</div><div>"multidimensional accesses" directly into LLVM to lower languages such as Fortran which have these "multi-dimensional" semantics. </div><div><br></div><div>The RFC is still work-in-progress, but feedback would be appreciated. We're trying to work out some of the rough edges out before posting it.</div><div><br></div><div>Thanks,</div><div>~Siddharth.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 25, 2019 at 12:31 AM Hubert Tong via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 24, 2019 at 3:55 PM Michael Kruse via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>[CC bollu, mferguson, shil]</div><div dir="ltr"><br></div><div dir="ltr">Am Do., 23. Mai 2019 um 17:13 Uhr schrieb Bardia Mahjour <<a href="mailto:bmahjour@ca.ibm.com" target="_blank">bmahjour@ca.ibm.com</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p><font size="2">Thanks David and Michael for the clarification. </font><br><br><font size="2">I think I understand the rational behind those checks in delinearization now.</font><br><br><tt><font size="2">> 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.</font></tt><br><br><font size="2">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? </font></p></div></blockquote><div><br></div><div>If the source is C/C++, the inrange keyword cannot be used because of the language's semantics (see below).</div><div><br></div><div>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). </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p><font size="2">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.</font><br></p></blockquote><div><br></div><div>For clarification: In C, subscripts themselves have no semantics, they are defined as syntactic sugar:</div><div><br></div><div>C18, 6.5.2.1,
§2</div><div><font face="arial, sans-serif"><span>> The definition of the subscript operator</span><span>[] </span><span>is that </span><span>E1[E2] </span><span>is identical</span> <span>to</span><span>(</span><span>*</span><span>((E1)+(E2)))</span></font><br></div><div><br></div><div>Using arithmetic properties, &A[1][0] == (char*)A + 2 == &A[0][2] (for an array declared "<i>char</i> A[2][2]"). The indirection operator (*) is only undefined if it yields to an access to an invalid address (C18, note 104).</div></div></div></blockquote><div>Yes, the addresses are equal, but you make a point of talking about the indirection operator.</div><div>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.</div><div><br></div><div>&A[0][2] produces a result that points one past the last element of the array A[0].<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Michael</div><div> </div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>