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

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

> 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

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.

-----Original Message-----
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).

-- 
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
>
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.llvm.org%2fcgi-bin%2fmailman%2flistinfo%2fllvm-dev&data=01%7c01%7candya%40microsoft.com%7cb090f0f61374453f83eb08d33e1f966f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=wmxiQu5Ok6W905PUvTR1hBR%2fk0Wy9Flxl9ELbiKXlS8%3d