<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Feb 26, 2016 at 7:08 PM Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com">sanjoy@playingwithpointers.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Feb 25, 2016 at 9:59 AM, Sanjoy Das<br>
<<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>> wrote:<br>
> 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>
^ This particular case above is already fixed in DeadArgElim:<br></blockquote><div><br></div><div>Fascinating. So I'm just proposing that we need to use similar logic in other IPO passes.</div><div><br></div><div>We should probably factor it. Maybe we just need to admit mayBeOverridden in more cases. It's not clear that there is any meaningful delta between what has been discussed and just putting these cases into that set.</div><div><br></div><div>-Chandler</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
bool DAE::RemoveDeadArgumentsFromCallers(Function &Fn)<br>
{<br>
  // We cannot change the arguments if this TU does not define the function or<br>
  // if the linker may choose a function body from another TU, even if the<br>
  // nominal linkage indicates that other copies of the function have the same<br>
  // semantics. In the below example, the dead load from %p may not have been<br>
  // eliminated from the linker-chosen copy of f, so replacing %p with undef<br>
  // in callers may introduce undefined behavior.<br>
  //<br>
  // define linkonce_odr void @f(i32* %p) {<br>
  //   %v = load i32 %p<br>
  //   ret void<br>
  // }<br>
  if (!Fn.isStrongDefinitionForLinker())<br>
    return false;<br>
<br>
-- Sanjoy<br>
</blockquote></div></div>