<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Elena Demikhovsky" <elena.demikhovsky@intel.com><br><b>To: </b>"Hal Finkel" <hfinkel@anl.gov><br><b>Cc: </b>"llvm-dev" <llvm-dev@lists.llvm.org>, "Richard Smith" <richard-llvm@metafoo.co.uk>, "Eli Friedman" <eli.friedman@gmail.com><br><b>Sent: </b>Tuesday, July 26, 2016 9:03:11 AM<br><b>Subject: </b>RE: [llvm-dev] Alias Analysis with inbound GEPs<br><br>


<style><!--

@font-face
        {font-family:Helvetica;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}

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
        {mso-style-priority:99;
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
span.EmailStyle18
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
        {page:WordSection1;}

@list l0
        {mso-list-id:799957587;
        mso-list-type:hybrid;
        mso-list-template-ids:-1214880770 44585902 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
        {mso-level-start-at:0;
        mso-level-number-format:bullet;
        mso-level-text:-;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:"Calibri",sans-serif;
        mso-fareast-font-family:"Times New Roman";}
@list l0:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:"Courier New";
        mso-bidi-font-family:"Times New Roman";}
@list l0:level3
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Wingdings;}
@list l0:level4
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Symbol;}
@list l0:level5
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:"Courier New";
        mso-bidi-font-family:"Times New Roman";}
@list l0:level6
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Wingdings;}
@list l0:level7
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Symbol;}
@list l0:level8
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:"Courier New";
        mso-bidi-font-family:"Times New Roman";}
@list l0:level9
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Wingdings;}
ol
        {margin-bottom:0cm;}
ul
        {margin-bottom:0cm;}
--></style>

<div class="WordSection1">
<p class="MsoNormal"><a name="_MailEndCompose"><span id="DWT56037" style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">In my case the “load” has the structure info, but the “store” does not:</span></a></p></div></blockquote>Yes, it looks like we just don't emit that TBAA structure information for accesses to array members. I suspect that improving that will fix this problem. We might need to extend the concept, however, to encompass that the access is "somewhere in this offset range." We might just need a definitional change, saying that the offset in the TBAA metadata represents the start of the field, even if we're only accessing some part of the field.<br><br>I think the first step here is probably to update the LangRef to actually reflect the metadata structure that we currently have.<br><br>Thanks again,<br>Hal<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div class="WordSection1"><p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"></span></a></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">  %54 = getelementptr inbounds %struct.s, %struct. s* %0, i64 0, i32 1, i64 %20, i64 %48, !dbg !48</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">  store double %53, double* %54, align 8, !dbg !49, !tbaa !41</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">!10 = !{!"omnipotent char", !11, i64 0}</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">!11 = !{!"Simple C/C++ TBAA"}</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">!12 = !{!"any pointer", !10, i64 0}</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">!13 = !{!"int", !10, i64 0}</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">!14 = !{!"double", !10, i64 0}</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">..</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">!41 = !{!14, !14, i64 0}</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<div>
<p class="MsoNormal" style="margin-left: 36pt; text-indent: -18pt;">
<span style="font-family: "Calibri",sans-serif; color: rgb(47, 84, 150);"><span style="">-<span style="font: 7pt "Times New Roman";">         
</span></span></span><span dir="LTR"></span><b><i><span style="color: rgb(47, 84, 150);"> Elena</span></i></b></p>
</div>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<div style="border-width: medium medium medium 1.5pt; border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; padding: 0cm 0cm 0cm 4pt;">
<div>
<div style="border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(225, 225, 225) -moz-use-text-color -moz-use-text-color; padding: 3pt 0cm 0cm;">
<p class="MsoNormal"><a name="_____replyseparator"></a><b><span style="font-size: 11pt; font-family: "Calibri",sans-serif;">From:</span></b><span style="font-size: 11pt; font-family: "Calibri",sans-serif;"> Hal Finkel [mailto:hfinkel@anl.gov]
<br>
<b>Sent:</b> Tuesday, July 26, 2016 15:33<br>
<b>To:</b> Demikhovsky, Elena <elena.demikhovsky@intel.com><br>
<b>Cc:</b> llvm-dev <llvm-dev@lists.llvm.org>; Richard Smith <richard-llvm@metafoo.co.uk>; Eli Friedman <eli.friedman@gmail.com><br>
<b>Subject:</b> Re: [llvm-dev] Alias Analysis with inbound GEPs</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal"><span style="font-size: 10pt; font-family: "Arial",sans-serif; color: black;"> </span></p>
<div class="MsoNormal" style="text-align: center;" align="center"><span style="font-size: 10pt; font-family: "Arial",sans-serif; color: black;">
<hr id="zwchr" align="center" size="2" width="100%">
</span></div>
<blockquote style="border-width: medium medium medium 1.5pt; border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(16, 16, 255); padding: 0cm 0cm 0cm 4pt; margin-left: 3.75pt; margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal" style="margin-bottom: 12pt;"><b><span style="font-family: "Helvetica",sans-serif; color: black;">From:
</span></b><span style="font-family: "Helvetica",sans-serif; color: black;">"Elena Demikhovsky" <<a href="mailto:elena.demikhovsky@intel.com" target="_blank">elena.demikhovsky@intel.com</a>><br>
<b>To: </b>"Hal J. Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>, "Eli Friedman" <<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>><br>
<b>Cc: </b>"llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>, "Richard Smith" <<a href="mailto:richard-llvm@metafoo.co.uk" target="_blank">richard-llvm@metafoo.co.uk</a>><br>
<b>Sent: </b>Tuesday, July 26, 2016 6:49:16 AM<br>
<b>Subject: </b>RE: [llvm-dev] Alias Analysis with inbound GEPs</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">>
</span><span style="color: black;">It seems like we might we able to use TBAA metadata with struct field information to get this then.</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">TBAA does not support struct fields yet.</span><span style="color: black;"></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">It shows what type will be stored, but does not have structure info.</span><span style="color: black;"></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size: 10pt; font-family: "Arial",sans-serif; color: black;">No, although, unfortunately, the documentation here seems like it is not up to date. I agree, however, that it might need some extension in this case. For example,<br>
<br>
$ cat /tmp/f.c <br>
struct S {<br>
  int x;<br>
  int y;<br>
};<br>
<br>
int foo(struct S *s) {<br>
  return s->x + s->y;<br>
};<br>
<br>
$ clang -O3 -S -emit-llvm -o - /tmp/f.c<br>
<br>
; ModuleID = '/tmp/f.c'<br>
source_filename = "/tmp/f.c"<br>
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"<br>
target triple = "x86_64-unknown-linux-gnu"<br>
<br>
%struct.S = type { i32, i32 }<br>
<br>
; Function Attrs: norecurse nounwind readonly uwtable<br>
define i32 @foo(%struct.S* nocapture readonly) local_unnamed_addr #0 {<br>
  %2 = getelementptr inbounds %struct.S, %struct.S* %0, i64 0, i32 0<br>
  %3 = load i32, i32* %2, align 4, !tbaa !1<br>
  %4 = getelementptr inbounds %struct.S, %struct.S* %0, i64 0, i32 1<br>
  %5 = load i32, i32* %4, align 4, !tbaa !6<br>
  %6 = add nsw i32 %5, %3<br>
  ret i32 %6<br>
}<br>
<br>
attributes #0 = { ... }<br>
<br>
!llvm.ident = !{!0}<br>
<br>
!0 = !{!"...."}<br>
!1 = !{!2, !3, i64 0}<br>
!2 = !{!"S", !3, i64 0, !3, i64 4}<br>
!3 = !{!"int", !4, i64 0}<br>
!4 = !{!"omnipotent char", !5, i64 0}<br>
!5 = !{!"Simple C/C++ TBAA"}<br>
!6 = !{!2, !3, i64 4}<br>
<br>
Note here that the two access to the structure have metadata nodes !1 and !6. If you look at those nodes, you'll see that (third argument), they identify the relevant field offset (0 bytes and 4 bytes in this case).<br>
<br>
 -Hal</span></p>
<blockquote style="border-width: medium medium medium 1.5pt; border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(16, 16, 255); padding: 0cm 0cm 0cm 4pt; margin-left: 3.75pt; margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span><span style="color: black;"></span></p>
<p class="MsoNormal"><span style="color: black;">> See also <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-July/102472.html" target="_blank">
http://lists.llvm.org/pipermail/llvm-dev/2016-July/102472.html</a> .</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(47, 85, 151);">It’s not, probably, the case. I need such “inbounds” for any sub-structure.</span><span style="color: black;"></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span><span style="color: black;"></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span><span style="color: black;"></span></p>
<div>
<p class="MsoNormal" style="margin-left: 36pt; text-indent: -18pt;"><span style="font-family: "Calibri",sans-serif; color: rgb(47, 84, 150);">-</span><span style="font-size: 7pt; color: rgb(47, 84, 150);">         
</span><b><i><span style="color: rgb(47, 84, 150);"> Elena</span></i></b><span style="color: black;"></span></p>
</div>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span><span style="color: black;"></span></p>
<div style="border-width: medium medium medium 1.5pt; border-style: none none none solid; padding: 0cm 0cm 0cm 4pt; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue;">
<div>
<div style="border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0cm 0cm; border-color: -moz-use-text-color;">
<p class="MsoNormal"><b><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: black;">From:</span></b><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: black;"> Finkel, Hal J. [<a href="mailto:hfinkel@anl.gov" target="_blank">mailto:hfinkel@anl.gov</a>]
<br>
<b>Sent:</b> Tuesday, July 26, 2016 02:03<br>
<b>To:</b> Eli Friedman <<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>><br>
<b>Cc:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; Demikhovsky, Elena <<a href="mailto:elena.demikhovsky@intel.com" target="_blank">elena.demikhovsky@intel.com</a>>; Richard Smith <<a href="mailto:richard-llvm@metafoo.co.uk" target="_blank">richard-llvm@metafoo.co.uk</a>><br>
<b>Subject:</b> Re: [llvm-dev] Alias Analysis with inbound GEPs</span><span style="color: black;"></span></p>
</div>
</div>
<p class="MsoNormal"><span style="color: black;"> </span></p>
<div>
<div>
<p class="MsoNormal"><i><span style="color: rgb(51, 51, 51);">Sent from my Verizon Wireless 4G LTE DROID</span></i><span style="color: black;"></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">On Jul 25, 2016 6:10 PM, Eli Friedman <<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>> wrote:</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">> On Mon, Jul 25, 2016 at 2:06 PM, Hal Finkel via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>> ________________________________</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> From: "Elena Demikhovsky" <<a href="mailto:elena.demikhovsky@intel.com" target="_blank">elena.demikhovsky@intel.com</a>></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> Cc: "llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> Sent: Monday, July 25, 2016 2:46:34 PM</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> Subject: RE: [llvm-dev] Alias Analysis with inbound GEPs</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>  </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>> I’m checking aliasing of two pointers:</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>>  </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>>   %GEP1 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0, i32 1, i64 %indvars.iv41, i64 %indvars.iv39</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>>   %GEP2 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0, i32 16</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>>  </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>> The result I got is “PartialAlias” because the indices of the GEP1 are variable.</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> That seems like a bug. PartialAlias should only be returned when we can prove a partial overlap. Otherwise, MayAlias should be returned.</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> [Demikhovsky, Elena] There are some comments inside:</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>   // Statically, we can see that the base objects are the same, but the</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>   // pointers have dynamic offsets which we can't resolve. And none of our</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>   // little tricks above worked.</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>   //</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>   // TODO: Returning PartialAlias instead of MayAlias is a mild hack; the</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>   // practical effect of this is protecting TBAA in the case of dynamic</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>  // indices into arrays of unions or malloc'd memory.</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>   return PartialAlias;</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>> Ah, thanks! That, unfortunately, makes sense.</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>  </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>> Shouldn’t the “inbounds” keyword mean that the access to sub-array is also in-bounds?</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> No. inbounds applies only to the whole object.</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>> I’m trying to reach “NoAlias” consensus between GEP1 and GEP2.</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> Did the original code come from C or C++? What are we modeling here?</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> [Demikhovsky, Elena] C-code:</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>                            for (m=0; m < params->num; m++) {</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>                                            params->a[i][m] = expr;</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>>                               }</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> %GEP1 is the store for params->a[i][m]</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> %GEP2 is the load for params->num.</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> The loop is not vectorized due to a possible collision between params->num and params->a[i][m]. If I take loading of params->num outside the loop, it is vectorized.</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>>> Bounds of array “a” are known at compile time. Limit of “i” and “m” are runtime variables.</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>> The problem is, IIRC, it is not undefined behavior to access one structure field by over-indexing an earlier array member. C++ has rules for "safely-derived pointers", and I think they include all pointer arithmetic
 on addresses from subobjects. If array access is just pointer arithmetic, I'm not sure that helps you as much as you'd like. cc'ing Richard to correct me if necessary.</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">>> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">> It is actually undefined behavior. This is explicitly called out in Annex J.2: "An array subscript is out of range, even if an object is apparently accessible with the given subscript (as in the lvalue expression
 a[1][7] given the declaration int a[4][5]) ".  If you break it apart into separate steps, the interesting bit is that the implicit array-to-pointer conversion is not equivalent to a cast; "int* b = (int*)a;" is not equivalent to "int* b = *a;", even though
 the expressions have the same type and value.</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">> There currently isn't any way to model the aliasing behavior of the address-of operator or array-to-pointer decay in LLVM IR. See also
<a href="http://lists.llvm.org/pipermail/llvm-dev/2016-July/102472.html" target="_blank">
http://lists.llvm.org/pipermail/llvm-dev/2016-July/102472.html</a> .</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">It seems like we might we able to use TBAA metadata with struct field information to get this then.</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">-Hal</span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="color: black;">> -Eli</span></p>
</div>
</div>
</div>
<p><span style="font-family: "Helvetica",sans-serif; color: black;">---------------------------------------------------------------------<br>
Intel Israel (74) Limited</span></p>
<p><span style="font-family: "Helvetica",sans-serif; color: black;">This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.</span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size: 10pt; font-family: "Arial",sans-serif; color: black;"><br>
<br>
<br>
-- </span></p>
<div>
<p class="MsoNormal"><span style="font-size: 10pt; font-family: "Arial",sans-serif; color: black;">Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory</span></p>
</div>
</div>
</div>
</div>
<p>---------------------------------------------------------------------<br>
Intel Israel (74) Limited</p>

<p>This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.</p></blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>