<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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"><br>I preserve them only weakly... I don't want full barriers; in fact, I plan to add InstCombine code to combine calls to @llvm.noalias (it will also take a list of scopes, not just one, so this is possible). The goal is to have as few barriers as possible.</blockquote><div><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Good.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></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><div class="h5">> > Going further, logically the intrinsic should return a pointer to a<br>
> > new object, disjoint from all other live objects. It is not aliased<br>
> > to A, and is well defined even if it contains &A because A is not<br>
> > referenced in the scope.<br>
><br>
> This is essentially what is done, but only for accesses in the scope<br>
> (or some sub-scope). I don't think the semantics allow for what<br>
> you're suggesting. The specific language from 6.7.3.1p4 says:<br>
><br>
> [from C]<br>
> During each execution of B, let L be any lvalue that has &L based on<br>
> P. If L is used to<br>
> access the value of the object X that it designates, ...,<br>
> then the following requirements apply: ... Every other lvalue<br>
> used to access the value of X shall also have its address based on P.<br>
> [end from C]<br>
><br>
> Where B is defined in 6.7.3.1p2 to be, essentially, the block in<br>
> which the relevant declaration appears. And we can really only<br>
> extrapolate from that to the other access in that block, and not to<br>
> the containing block.<br>
><br>
><br>
> Inside that block<br>
> (the lifetime of P) , it is safe to assume that X is<br>
> disjoint from an arbitrary live object<br>
> A. It if was<br>
><br>
> n't<br>
> , either:<br>
> - A is independently referenced inside the block, so there is UB and<br>
> all bets are off.<br>
> - A is not independently referenced inside the blo ck,<br>
</div></div>> so t here are no pairs of accesses to incorrectly reorder as all<br>
<span class="">> accesses to A in<br>
> the block are done through P. You just need to delimit the block<br>
> with dataflow barriers<br>
> , summar iz<br>
> ing the effect of the block at entry/exit.<br>
<br>
</span>Okay, I think I agree with you assuming that we put in entry/exit barriers to preserve the block boundaries. I'd specifically like to avoid that, however.<span class=""><br></span></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">I'm not proposing full code motion barriers, only punctual dataflow use/defs to signal entry/exit to the scope. </div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><div class="gmail_default">Logically, entering the scope transfers the pointed data into a new unique block of memory, and puts its address on the restrict pointer. Exiting the scope transfers it back. Of course you do not want to actually allocate a new object and move the data, but you can use these semantics to define the scope entry/exit intrinsics. Their contribution to dataflow is only limited to the content of the address used to initialize the restricted pointer. These would be lighter than the proposed intrinsic as they would not have specialized control-flow restrictions.</div><div><br></div></div><div class="gmail_default" style="font-family:verdana,sans-serif">This approach makes the restrict attribute effective against all live variables without having to examine the extent of the scope to collect all references, which is in general impractical. It also removes the need for scope metadata, as there would be no need to name the scopes.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Anyway, this is just a general alternate design, since you were asking for one. I'm sure still would take some time/effort to map it onto the LLVM framework.</div></div><div class="gmail_default" style="font-family:verdana,sans-serif"><div class=""><div class="h5"><br></div><div class="h5">Regards,</div><div class="h5"><br></div><div class="h5"><br></div></div></div></div></div></div>