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

[Andy Ayers via llvm-dev]

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.

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. 

-----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