<html><body><p><font size="2">Hi Siddharth,</font><br><br><font size="2">I'd be interested in taking a look at your proposal once it becomes available.</font><br><br><font size="2">Thanks,</font><br><br><font size="2">Bardia Mahjour<br>Compiler Optimizations<br>Hydra Squad Lead<br>IBM Toronto Software Lab<br>bmahjour@ca.ibm.com (905) 413-2336<br><br></font><br><br><img width="16" height="16" src="cid:1__=8FBB0E9ADFF325C38f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Siddharth Bhat via llvm-dev ---2019/05/29 04:46:57 AM---Hello, After Sahil's GSoC 2018 project on int"><font size="2" color="#424282">Siddharth Bhat via llvm-dev ---2019/05/29 04:46:57 AM---Hello, After Sahil's GSoC 2018 project on integrating Chapel into Polly</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Siddharth Bhat via llvm-dev <llvm-dev@lists.llvm.org></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Hubert Tong <hubert.reinterpretcast@gmail.com></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">"llvm-dev@lists.llvm.org" <llvm-dev@lists.llvm.org>, SAHIL GIRISH YERAWAR <cs15btech11044@iith.ac.in>, nd <nd@arm.com>, Michael Ferguson <mferguson@cray.com></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">2019/05/29 04:46 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">[EXTERNAL] Re: [llvm-dev] Delinearization validity checks in DependenceAnalysis</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2">"llvm-dev" <llvm-dev-bounces@lists.llvm.org></font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br>Hello,<br><br>After <a href="http://pollylabs.org/gsoc2018/Compiling-Chapel-with-Polly-and-LLVM.html"><u><font color="#0000FF">Sahil's GSoC 2018 project on integrating Chapel into Polly</font></u></a>, and running into similar issues with delinearization multiple times before, we began drafting up an RFC to introduce these kinds of<br>"multidimensional accesses" directly into LLVM to lower languages such as Fortran which have these "multi-dimensional" semantics. <br><br>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.<br><br>Thanks,<br>~Siddharth.<br><br><br>On Sat, May 25, 2019 at 12:31 AM Hubert Tong via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org"><u><font color="#0000FF">llvm-dev@lists.llvm.org</font></u></a>> wrote:
<ul>On Fri, May 24, 2019 at 3:55 PM Michael Kruse via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"><u><font color="#0000FF">llvm-dev@lists.llvm.org</font></u></a>> wrote:<br>[CC bollu, mferguson, shil]<br><br>Am Do., 23. Mai 2019 um 17:13 Uhr schrieb Bardia Mahjour <<a href="mailto:bmahjour@ca.ibm.com" target="_blank"><u><font color="#0000FF">bmahjour@ca.ibm.com</font></u></a>>:
<ul><font size="2">Thanks David and Michael for the clarification. </font><br><font size="2"><br>I think I understand the rational behind those checks in delinearization now.</font><br><tt><font size="2"><br>> 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><font size="2"><br>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></ul><br><br>If the source is C/C++, the inrange keyword cannot be used because of the language's semantics (see below).<br><br>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). <br>
<ul><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></ul><br><br>For clarification: In C, subscripts themselves have no semantics, they are defined as syntactic sugar:<br><br>C18, 6.5.2.1, §2<br><font face="Arial">> The definition of the subscript operator[] is that E1[E2] is identical to(*((E1)+(E2)))</font><br><br>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).<br>Yes, the addresses are equal, but you make a point of talking about the indirection operator.<br>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.<br><br>&A[0][2] produces a result that points one past the last element of the array A[0].<br> <br><br>Michael<br> <br>_______________________________________________<br>LLVM Developers mailing list<u><font color="#0000FF"><br></font></u><a href="mailto:llvm-dev@lists.llvm.org" target="_blank"><u><font color="#0000FF">llvm-dev@lists.llvm.org</font></u></a><u><font color="#0000FF"><br></font></u><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank"><u><font color="#0000FF">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</font></u></a><br>_______________________________________________<br>LLVM Developers mailing list<u><font color="#0000FF"><br></font></u><a href="mailto:llvm-dev@lists.llvm.org" target="_blank"><u><font color="#0000FF">llvm-dev@lists.llvm.org</font></u></a><u><font color="#0000FF"><br></font></u><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank"><u><font color="#0000FF">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</font></u></a><tt><font size="2">_______________________________________________<br>LLVM Developers mailing list<br>llvm-dev@lists.llvm.org<br></font></tt><tt><font size="2"><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></font></tt><tt><font size="2"><br></font></tt><br><br></ul><BR>
</body></html>