similar to: Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")

While we're talking about this, I'd just mention again that the same issue arises for *normal* functions too, when linked into a shared library: int foo() { return 1; } int bar() { return foo(); } Now, compare: clang -fPIC -O1 -S -o - test.c gcc -fPIC -O1 -S -o - test.c GCC will refuse to inline foo into bar, or use any information about foo in compiling bar, because foo is

> On 2016-Feb-24, at 15:57, Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > This is something that came up in the "RFC: Add guard intrinsics to > LLVM" thread; and while I'm not exactly blocked on this, figuring out > a path forward here will be helpful in deciding if we can use the > available_externally linkage type to

On Wed, Feb 24, 2016 at 6:51 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> If we do not inline @foo(), and instead re-link the call site in @main >> to some non-optimized copy (or differently optimized copy) of @foo, >> then it is possible for the program to have the behavior {print("Y"); >> print ("X")}, which was disallowed in

On Wed, Feb 24, 2016 at 7:10 PM Sanjoy Das via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Wed, Feb 24, 2016 at 6:51 PM, Duncan P. N. Exon Smith > <dexonsmith at apple.com> wrote: > >> If we do not inline @foo(), and instead re-link the call site in @main > >> to some non-optimized copy (or differently optimized copy) of @foo, > >> then it is

On Mon, Feb 22, 2016 at 11:18 PM, Chandler Carruth <chandlerc at gmail.com> wrote: >> # step A: Introduce an `interposable` function attribute >> >> We can bike shed on the name and the exact specification, but the >> general idea is that you cannot do IPA / IPO over callsites calling >> `interposable` functions without inlining them. This attribute will

> On 2016-Feb-24, at 19:17, Chandler Carruth <chandlerc at google.com> wrote: > > On Wed, Feb 24, 2016 at 7:10 PM Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Wed, Feb 24, 2016 at 6:51 PM, Duncan P. N. Exon Smith > <dexonsmith at apple.com> wrote: > >> If we do not inline @foo(), and instead re-link the call site in @main > >>

Assuming everyone is on the same page, here's a rough high level agenda: # step A: Introduce an `interposable` function attribute We can bike shed on the name and the exact specification, but the general idea is that you cannot do IPA / IPO over callsites calling `interposable` functions without inlining them. This attribute will (usually) have to be used on function bodies that can

----- Original Message ----- > From: "James Y Knight via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Sanjoy Das" <sanjoy at playingwithpointers.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, February 25, 2016 1:41:43 PM > Subject: Re: [llvm-dev] Possible soundness issue with > available_externally (split

> On Feb 25, 2016, at 11:41 AM, James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > While we're talking about this, I'd just mention again that the same issue arises for *normal* functions too, when linked into a shared library: > int foo() { return 1; } > int bar() { return foo(); } > > Now, compare: > clang -fPIC -O1 -S -o - test.c

Couple of other problematic transforms: # undef refinement After thinking about this a bit, I think undef refinement happens a lot more often than I initially thought, and it happens implicitly. Consider the following case: void @foo(int* ptr) available_externally { int k = *ptr; if (k == 1 && k == 2) print("X"); } void main() { int* ptr = malloc();

On Wed, Feb 24, 2016 at 7:38 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Wed, Feb 24, 2016 at 7:34 PM Duncan P. N. Exon Smith > <dexonsmith at apple.com> wrote: >> >> >> > On 2016-Feb-24, at 19:17, Chandler Carruth <chandlerc at google.com> wrote: >> > >> > On Wed, Feb 24, 2016 at 7:10 PM Sanjoy Das via llvm-dev >>

On 02/24/2016 08:10 PM, Duncan P. N. Exon Smith via llvm-dev wrote: >> On 2016-Feb-24, at 19:46, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: >> >> On Wed, Feb 24, 2016 at 7:38 PM, Chandler Carruth <chandlerc at google.com> wrote: >>> On Wed, Feb 24, 2016 at 7:34 PM Duncan P. N. Exon Smith >>> <dexonsmith at apple.com> wrote:

----- Original Message ----- > From: "Chandler Carruth via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Philip Reames" <listmail at philipreames.com>, "Duncan P. N. Exon > Smith" <dexonsmith at apple.com>, "Sanjoy Das" > <sanjoy at playingwithpointers.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>

> On Feb 24, 2016, at 9:41 PM, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Feb 24, 2016 at 9:35 PM Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote: > ----- Original Message ----- > > > From: "Chandler Carruth via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at

Yea, I'm pretty sad about all of this. I'm also not seeing a lot of awesome paths forward. Here is the least bad strategy I can come up with. Curious if folks think this is sufficient: 1) Stop deducing function attributes within comdats by examining the bodies of the functions (so that we remain free to transform the bodies of functions). 2) Teach frontends to emit (even at O0!!!)

On Wed, Feb 24, 2016 at 9:35 PM Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > > From: "Chandler Carruth via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "Philip Reames" <listmail at philipreames.com>, "Duncan P. N. Exon > > Smith" <dexonsmith at apple.com>, "Sanjoy Das" > >

On Wed, Feb 24, 2016 at 7:34 PM Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2016-Feb-24, at 19:17, Chandler Carruth <chandlerc at google.com> wrote: > > > > On Wed, Feb 24, 2016 at 7:10 PM Sanjoy Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > On Wed, Feb 24, 2016 at 6:51 PM, Duncan P. N. Exon Smith > >

> On Feb 24, 2016, at 10:20 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > ----- Original Message ----- > >> From: "Mehdi Amini" <mehdi.amini at apple.com> >> To: "Chandler Carruth" <chandlerc at google.com> >> Cc: "Hal Finkel" <hfinkel at anl.gov>, "llvm-dev" >> <llvm-dev at

On Tue, Feb 23, 2016 at 10:55 AM, Chandler Carruth <chandlerc at gmail.com> wrote: >> Part of the challenge here is to specify the attribute in a way that >> allows inlining, but not IPA without inlining. In fact, maybe it is >> best to not call it "interposable" at all? > > > Yea, this is something *very* different from interposable. GCC and other >

> On 2016-Feb-24, at 19:46, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > On Wed, Feb 24, 2016 at 7:38 PM, Chandler Carruth <chandlerc at google.com> wrote: >> On Wed, Feb 24, 2016 at 7:34 PM Duncan P. N. Exon Smith >> <dexonsmith at apple.com> wrote: >>> >>> >>>> On 2016-Feb-24, at 19:17, Chandler Carruth