<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 26, 2016 at 6:10 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Sanjoy,<br>
<br>
These are both very interesting examples, and demonstrate that the problems extends beyond function attributes (encompassing dead-argument elimination, etc.).<br>
<br>
I'm beginning to think that the best solution, at least when optimizing for speed, is the one that David Li suggested: we need to internalize functions that have been optimized in certain ways (e.g. instructions with potential side effects are removed). The trick here may be to be as intelligent about this as possible to minimize the effect on code size. Maybe this is as easy as checking whether isSafeToSpeculativelyExecute returns false on the deleted instruction? Perhaps when optimizing for size, we need to forbid such deletions.<br></blockquote><div><br></div><div>In general, if a (multi-TU) function's attribute is changed in any way that is different from the default 'attribute', the function needs to be privatized. This is not that different from function cloning during inter-procedural constant propagation.  Andy mentioned the example about the function 'attribute' related to modifying caller save registers. </div><div><br></div><div>David</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks again,<br>
Hal<br>
<span class="im HOEnZb"><br>
----- Original Message -----<br>
> From: "Sanjoy Das" <<a href="mailto:sanjoy@playingwithpointers.com">sanjoy@playingwithpointers.com</a>><br>
</span><span class="im HOEnZb">> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
> Cc: "Chandler Carruth" <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>>, "llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>, "Philip Reames"<br>
> <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>>, "Duncan P. N. Exon Smith" <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>><br>
> Sent: Thursday, February 25, 2016 11:59:27 AM<br>
> Subject: Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")<br>
><br>
</span><div class="HOEnZb"><div class="h5">> Couple of other examples:<br>
><br>
>   void @foo(i32* %ptr) available_externally {<br>
>     %discard = load i32, i32* %ptr<br>
>   }<br>
>   void bar() {<br>
>     call @foo(i32* %x)<br>
>   }<br>
><br>
> ==><br>
><br>
>   void @foo(i32* %ptr) available_externally {<br>
>   }<br>
>   void bar() {<br>
>     call @foo(i32* %x)<br>
>   }<br>
><br>
> ==><br>
><br>
>   void @foo(i32* %ptr) available_externally {<br>
>   }<br>
>   void bar() {<br>
>     call @foo(i32* undef) ;; non optimized @foo will crash<br>
>   }<br>
><br>
>   ;; Similar example if @foo was dividing something by an integer<br>
>   ;; argument<br>
><br>
> We've actually seen the above in our VM (though back then we<br>
> didn't realize that the problem was more general than the one<br>
> case above).<br>
><br>
> Another one involving `undef` (semantically same as "folding undef",<br>
> but different enough to state separately):<br>
><br>
>   void @foo(i32* %ptr) available_externally {<br>
>     store i32 undef, i32* %ptr<br>
>   }<br>
>   void bar() {<br>
>     %val = load i32, i32* %x<br>
>     call @foo(i32* %x)<br>
>   }<br>
><br>
> ==><br>
><br>
>   void @foo(i32* %ptr) readonly available_externally {<br>
>   }<br>
>   void bar() {<br>
>     %val = load i32, i32* %x<br>
>     call @foo(i32* %x)<br>
>   }<br>
><br>
> ==><br>
><br>
>   void @foo(i32* %ptr) readonly available_externally {<br>
>   }<br>
>   void bar() {<br>
>     call @foo(i32* %x)<br>
>     %val = load i32, i32* %x<br>
>   }<br>
><br>
> With a non-optimized @foo, %val can be garbage.<br>
><br>
><br>
> I'll also note we've not really had bug reports (that I'm aware of)<br>
> around this issue.  Given that, it is possible that this is a purely<br>
> theoretical problem.<br>
><br>
> -- Sanjoy<br>
><br>
<br>
</div></div><div class="HOEnZb"><div class="h5">--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div></div></blockquote></div><br></div></div>