<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 25, 2016 at 11:27 AM, Andy Ayers via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A couple things I recall from implementing this in Phoenix:<br>
<br>
For LTO -- do your comdat folding as part of the up-front symbol resolution before invoking the backend (saves compile time too). Then have the linker ensure that the comdat from the LTO bundle is the winner in the final link step. That way during LTO you know which method body is going to be in the final image. May not be as easy in LLVM if you can't merge all the LTO objs into a single massive obj like we did.<br>
<br>
For non-LTO compiles: block bottom-up propagation of facts that depend on optimization levels -- eg register kills and parameter usage summaries. Allow other IP information to flow upwards, since at least in our world all comdat-foldable definitions are supposed to be "equivalent". Requires some discipline so you are confident you know how information is derived.<br></blockquote><div><br></div><div>Functions which have gone through 'unsafe' transformations should be 'internalized'. Have you tried that approach?</div><div><br></div><div>thanks,</div><div><br></div><div>David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We would also error out if foldable definitions did not appear to be equivalent. I think we at least wrote the code to do some sanity checking. Maybe we never turned this bit on.<br>
<br>
We had real bugs reported before we fixed this properly. One annoying one was that the comdat winner picked by the linker depended in part on the file path to the obj, so if you linked the program in different directories, you'd get different final binaries, and some of them would crash.<br>
<span class=""><br>
-----Original Message-----<br>
From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org">llvm-dev-bounces@lists.llvm.org</a>] On Behalf Of Sanjoy Das via llvm-dev<br>
Sent: Thursday, February 25, 2016 9:59 AM<br>
To: Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
</span><span class="">Subject: Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")<br>
<br>
</span><div><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 didn't realize that the problem was more general than the one case above).<br>
<br>
Another one involving `undef` (semantically same as "folding undef", 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) around this issue. Given that, it is possible that this is a purely theoretical problem.<br>
<br>
-- Sanjoy<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
</div></div><a href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.llvm.org%2fcgi-bin%2fmailman%2flistinfo%2fllvm-dev%0a&data=01%7c01%7candya%40microsoft.com%7cf0dc286d1dc04d5daf9408d33e0d7a98%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ZK9BbJxV6%2bcAQn%2ftdy3%2b%2fHyOA7BR5QclvKO1egIap0w%3d" rel="noreferrer" target="_blank">https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.llvm.org%2fcgi-bin%2fmailman%2flistinfo%2fllvm-dev%0a&data=01%7c01%7candya%40microsoft.com%7cf0dc286d1dc04d5daf9408d33e0d7a98%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ZK9BbJxV6%2bcAQn%2ftdy3%2b%2fHyOA7BR5QclvKO1egIap0w%3d</a><br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>