[llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")

[Mehdi Amini via llvm-dev]

> On Feb 25, 2016, at 12:02 PM, Andy Ayers via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> I recall it was things we could deduce by scanning the method before we optimized it, eg deduced noreturn/nothrow. I'd have to go check to be sure.

Yes, my understanding is that this is what Chandler suggested when he wrote as part of his plan:

2) Teach frontends to emit (even at O0!!!) trivially deduced function attributes for comdats so that we continue to catch easy cases.

It is not clear how powerful it'll be outside of trivial cases.

> Once you allow inlining, you're pretty much telling your users they had better give you compatible definitions. 
> 
> We wanted to make sure that if users gave us compatible defs (mainly: same source, but optimized in one CU and not in another), we wouldn't screw things up. 

Optimized in one CU and not the other is a good recipe to break these cases, but I believe even with the same optimizations in both CU, the context can end up with different IPA results (for example if a callee of the linkonce is available in one CU but not the other).

-- 
Mehdi



> 
> -----Original Message-----
> From: Sanjoy Das [mailto:sanjoy at playingwithpointers.com] 
> Sent: Thursday, February 25, 2016 11:36 AM
> To: Andy Ayers <andya at microsoft.com>
> Cc: Hal Finkel <hfinkel at anl.gov>; llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")
> 
> On Thu, Feb 25, 2016 at 11:27 AM, Andy Ayers <andya at microsoft.com> wrote:
>> 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.
> 
> For Phoenix, what kinds of things constituted "other IP information"?
> 
> -- Sanjoy
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev