[llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")
Andy Ayers via llvm-dev
llvm-dev at lists.llvm.org
Thu Feb 25 12:53:11 PST 2016
The opt/not-opt cases were the ones that caused our bug reports. It's a pretty easy mistake to make.
A few specific examples I know of:
Optimized callee doesn't kill some caller save. We propagate this up, callers allocate the reg across a call site. Linker swaps in debug version which kills the reg. Crash.
Debug callee read-derefs some pointer arg, but ignores the result. Optimized callee doesn't do the read anymore. We propagate that this param is dead upwards. Callers dead code the arg computation and pass null to save work on their side. Linker swaps in debug version. Crash.
Optimized differently, from what I remember, never caused us trouble. Maybe we were lucky.
From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com]
Sent: Thursday, February 25, 2016 12:10 PM
To: Andy Ayers <andya at microsoft.com>
Cc: Sanjoy Das <sanjoy at playingwithpointers.com>; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")
> 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).
> -----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
More information about the llvm-dev