<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:493254913;
mso-list-type:hybrid;
mso-list-template-ids:-1814537872 134807567 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1
{mso-list-id:719093459;
mso-list-template-ids:1359391948;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>A general comment: Obviously there's two stages<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>extracting "independence" information implicit in C like languages, eg, that an expression is actually a well-behaved multidimensional index<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>figuring out what further, possibly platform specific, optimizations to do once you've got an "independent" representation<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Naturally there's a lot of interest in dealing with existing+new codes written in C-type languages, but there's also compiling from other languages where the semantics already assures many of these properties. It would be helpful if there was a semi-stable LLVM-IR+metadata representation that systems for those languages could output directly. (I'm thinking of things like being able to state directly that loop interchange doesn't affect the semantics, as inference of this fact may well fail in some moderately complex cases, particularly if the "high-level" compiler does aggressive "array re-use".)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Regards,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>David<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> llvm-commits-bounces@cs.uiuc.edu [mailto:llvm-commits-bounces@cs.uiuc.edu] <b>On Behalf Of </b>Preston Briggs<br><b>Sent:</b> 25 September 2012 04:24<br><b>To:</b> Sebastian Pop<br><b>Cc:</b> Tobias Grosser; llvm-commits@cs.uiuc.edu<br><b>Subject:</b> Re: [llvm-commits] dependence analysis (of multi dimensional arrays)<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I think we should do two things:<o:p></o:p></p><div><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1'>We should write code to automatically delinearize where ever possible, and<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1'>We should change the IR (extend the GEP instruction) so that Clang doesn't have to linearize all multi-dimensional array references.<o:p></o:p></li></ol><p class=MsoNormal style='margin-bottom:12.0pt'>I think we need (1) because much existing code is already linearized. I think we need (2) because delinearization isn't able to handle all subscripts and we'll lose information. In particular, delinearization can't handle couple subscripts (I believe), things like:<o:p></o:p></p></div><blockquote style='margin-left:30.0pt;margin-right:0cm'><div><p class=MsoNormal><b><span style='font-family:"Courier New"'> for (i = 0; i < m; i++) {</span></b><o:p></o:p></p></div><div><p class=MsoNormal><b><span style='font-family:"Courier New"'> for (j = 0; j < n; j++) {</span></b><o:p></o:p></p></div><div><p class=MsoNormal><b><span style='font-family:"Courier New"'> A[i][j] = ...</span></b><o:p></o:p></p></div><div><p class=MsoNormal><b><span style='font-family:"Courier New"'> ... = A[j][i];</span></b><o:p></o:p></p></div><div><p class=MsoNormal><b><span style='font-family:"Courier New"'> }</span></b><o:p></o:p></p></div><div><p class=MsoNormal><b><span style='font-family:"Courier New"'> }</span></b><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></blockquote><div><p class=MsoNormal>Of course, we can begin with delinearization, extending the GEP later. My thought would be to build delinearization into the dependence analyzer, using it to attack MIV subscripts only.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I'll reread Maslov (Wolfe's book also discusses the topic in Section 7.2.4) and see if I can get back up to speed.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>To extend the GEP, it seems like we need to provide 2 fields for every dimension: size and subscript, where size is loop invariant.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Preston<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'><br>On Mon, Sep 24, 2012 at 2:15 PM, Sebastian Pop <<a href="mailto:spop@codeaurora.org" target="_blank">spop@codeaurora.org</a>> wrote:<br>> Hi Preston,<br>><br>> +// In addition, the implementation depends on the GEP instruction to<br>> +// differentiate subscripts. Unfortunately, since Clang linearizes subscripts<br>> +// for most arrays, this will be inadequate. We trust that the GEP instruction<br>> +// will eventually be extended.<br>> +//<br>> +// In the meantime, we should explore Maslov's ideas about delinearization.<br>><br>> I haven't had the chance to discuss with you about the linearized<br>> multi-dimensional<br>> array problem, and Tobias Grosser was also interested to know your point of view<br>> on reconstructing the higher level representation based on the linear form.<br>><br>> Could you please provide more details on what should be done to address this<br>> problem in LLVM or Clang?<br>><br>> Thanks,<br>> Sebastian<br>> --<br>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,<br>> hosted by The Linux Foundation<o:p></o:p></p></div></div></body></html>