<div dir="ltr">The second.<div><div><br></div><div><br></div><div><div>langref says:<br></div><div>"<span style="color:rgb(0,0,0);font-family:'Lucida Grande','Lucida Sans Unicode',Geneva,Verdana,sans-serif;font-size:14px;line-height:21px">The </span><em style="color:rgb(0,0,0);font-family:'Lucida Grande','Lucida Sans Unicode',Geneva,Verdana,sans-serif;font-size:14px;line-height:21px">in bounds</em><span style="color:rgb(0,0,0);font-family:'Lucida Grande','Lucida Sans Unicode',Geneva,Verdana,sans-serif;font-size:14px;line-height:21px"> addresses for an allocated object are all the addresses that point into the object, plus the address one byte past the end. In cases where the base is a vector of pointers the </span><tt class="" style="font-family:Consolas,'Deja Vu Sans Mono','Bitstream Vera Sans Mono',monospace;font-size:0.95em;color:rgb(0,0,0);line-height:21px"><span class="">inbounds</span></tt><span style="color:rgb(0,0,0);font-family:'Lucida Grande','Lucida Sans Unicode',Geneva,Verdana,sans-serif;font-size:14px;line-height:21px"> keyword applies to each of the computations element-wise."</span></div><div><div><br></div><div>Presumably, the allocated object here is ps, *not* the fields.</div></div><div><br></div><div><br></div><div>Interestingly, the GEP faq says:"A <span style="color:rgb(0,0,0);font-family:'Lucida Grande','Lucida Sans Unicode',Geneva,Verdana,sans-serif;font-size:14px;line-height:21px">common example of how this is used is arrays where the size is not known. It’s common to use array types with zero length to represent these. The fact that the static type says there are zero elements is irrelevant; it’s perfectly valid to compute arbitrary element indices, as the computation only depends on the size of the array element, not the number of elements. Note that zero-sized arrays are not a special case here. </span><span style="color:rgb(0,0,0);font-family:'Lucida Grande','Lucida Sans Unicode',Geneva,Verdana,sans-serif;font-size:14px;line-height:21px">This sense is unconnected with </span><tt class="" style="font-family:Consolas,'Deja Vu Sans Mono','Bitstream Vera Sans Mono',monospace;font-size:0.95em;color:rgb(0,0,0);line-height:21px"><span class="">inbounds</span></tt><span style="color:rgb(0,0,0);font-family:'Lucida Grande','Lucida Sans Unicode',Geneva,Verdana,sans-serif;font-size:14px;line-height:21px"> keyword. The </span><tt class="" style="font-family:Consolas,'Deja Vu Sans Mono','Bitstream Vera Sans Mono',monospace;font-size:0.95em;color:rgb(0,0,0);line-height:21px"><span class="">inbounds</span></tt><span style="color:rgb(0,0,0);font-family:'Lucida Grande','Lucida Sans Unicode',Geneva,Verdana,sans-serif;font-size:14px;line-height:21px"> keyword is designed to describe low-level pointer arithmetic overflow conditions, rather than high-level array indexing rules."</span></div><div><br></div><div><br></div><div>At least this leads me to believe you can't use the "llvm type" info much at all in conjunction with inbounds, only the size of allocas that you see.</div><div><br></div><div>--Dan</div><br><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 10, 2015 at 11:00 AM, Pete Cooper <span dir="ltr"><<a href="mailto:peter_cooper@apple.com" target="_blank">peter_cooper@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Dec 10, 2015, at 8:09 AM, Daniel Berlin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div></div></blockquote></span><div>Opps, you are right in my example basicaaa could do it potentially. Correct example is slightly different:</div><span><div>int foo(struct S *ps, int i) {<br></div></span><div><span><div> ps->a[i] = 1;</div><div> ps->b = 2;</div></span><div> return ps->a[i];</div><div>}</div></div><div>Here basicaa cannot make sure that 'ps->a[i]' doesn't change after 'ps->b = 2' because if 'i == 10' all 3 memory accesses will read/write the same memory. And type information about S::a is required to disambiguate. With current TBAA 'ps->a[i]' is about random 'int' read.</div></div></div></div></blockquote><div><br></div><div>Yes, and without more info, in LLVM that read can legally touch ps->b.</div></div></div></div></div></blockquote></span>I thought the inbounds on the GEPs would have told us that the a[] accesses and b access are both in bounds of their respective fields of the struct.</div><div><br></div><div>Or does inbounds only tell us that the GEPs are in bounds of ‘ps’ itself?</div><div><blockquote type="cite"><div><span class=""><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>So that makes sense.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Missing information here is the range inside struct S that could be accessed. </div></div></blockquote><div><br></div></span><div>What do you mean by "could be accessed". Do you mean "valid to access in C"?</div></div></div></div></blockquote><div><br></div></span><div>By access I meant read/write memory i.e. that size of S::a inside the struct or at least information that only S::a is accessed in this place i.e. not S::b.</div></div></div></div></blockquote><div><br></div><div>Okay.</div><div><br></div><div>So what you want sounds reasonable to me ;-)</div><div><br></div></div></div></div></span><span class="">
_______________________________________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></span></div></blockquote></div><br></div></blockquote></div><br></div>