search for: available_external

Couple of other examples: void @foo(i32* %ptr) available_externally { %discard = load i32, i32* %ptr } void bar() { call @foo(i32* %x) } ==> void @foo(i32* %ptr) available_externally { } void bar() { call @foo(i32* %x) } ==> void @foo(i32* %ptr) available_externally { } void bar() { call @foo(i32* undef) ;; non optimi...

...h folding undefs independent of the > previous two items, but we thus-far lack a concrete example. We don't yet have enough information. I don't have a good example for (c), but if you go by the textbook "is a non-deterministic value" definition for undef then void foo() available_externally { %x = create_undef(); if (%x) print("X"); } is just as problematic as the two atomic loads case. This isn't a good example though, since we can specify as part of `undef` s semantics: "if the program has different observable behavior based on undef's non-det...

...t;llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" > <listmail at philipreames.com>, "Duncan P. N. Exon Smith" <dexonsmith at apple.com> > Sent: Thursday, February 25, 2016 11:59:27 AM > Subject: Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics") > > Couple of other examples: > > void @foo(i32* %ptr) available_externally { > %discard = load i32, i32* %ptr > } > void bar() { > call @foo(i32* %x) > } > > ==> > > void @foo(i32*...

...dev at lists.llvm.org>, "Philip Reames" > > <listmail at philipreames.com>, "Duncan P. N. Exon Smith" < > dexonsmith at apple.com> > > Sent: Thursday, February 25, 2016 11:59:27 AM > > Subject: Re: [llvm-dev] Possible soundness issue with > available_externally (split from "RFC: Add guard intrinsics") > > > > Couple of other examples: > > > > void @foo(i32* %ptr) available_externally { > > %discard = load i32, i32* %ptr > > } > > void bar() { > > call @foo(i32* %x) > > } &gt...

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(); *ptr = 200; @foo(ptr) } => void @foo(int* ptr) readnone available_externally { //int k = *ptr; //if (false) print("X"); } void main() {...

...inal Message----- From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Sanjoy Das via llvm-dev Sent: Thursday, February 25, 2016 9:59 AM To: Hal Finkel <hfinkel at anl.gov> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics") Couple of other examples: void @foo(i32* %ptr) available_externally { %discard = load i32, i32* %ptr } void bar() { call @foo(i32* %x) } ==> void @foo(i32* %ptr) available_externally { } void bar() { call @foo(i32...

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 expression certain semantic properties guard intrinsics will have. Let's start with an example that shows that we have a problem (direct copy/paste from the guard intrinsics thread). Say we have: ``` void foo() available_externally { %t0 = load atomic %ptr %t1 = load ato...

On Thu, Jun 4, 2015 at 11:27 AM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > Since the compiler is always free to delete available_externally > functions, I think you could just add a pass to the -flto=thin pipeline > that deletes all of them (referenced or not) -- it's just a single loop > through all the functions deleting the bodies of those with the right > linkage. I imagine there are other pass pipelines that mig...

On Thu, Feb 25, 2016 at 9:59 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Couple of other examples: > > void @foo(i32* %ptr) available_externally { > %discard = load i32, i32* %ptr > } > void bar() { > call @foo(i32* %x) > } > > ==> > > void @foo(i32* %ptr) available_externally { > } > void bar() { > call @foo(i32* %x) > } > > ==> > > void @foo(i32* %ptr)...

...< 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 expression certain semantic > properties guard intrinsics will have. > > Let's start with an example that shows that we have a problem (direct > copy/paste from the guard intrinsics thread). Say we have: > > ``` > void foo() available_externally { > %...

On Fri, Feb 26, 2016 at 7:08 PM Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > On Thu, Feb 25, 2016 at 9:59 AM, Sanjoy Das > <sanjoy at playingwithpointers.com> wrote: > > Couple of other examples: > > > > void @foo(i32* %ptr) available_externally { > > %discard = load i32, i32* %ptr > > } > > void bar() { > > call @foo(i32* %x) > > } > > > > ==> > > > > void @foo(i32* %ptr) available_externally { > > } > > void bar() { > > call @foo(i32* %x)...

Chandler Carruth <chandlerc at google.com> writes: > On Thu, Feb 25, 2016 at 10:40 PM Justin Bogner via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> I am *way* out of my depth here, but what if 'c' was an 'unsigned >>> char' (and not an 'int')?  Wouldn't that prevent UB, since it is >>> escaped (cannot be a register

...hilip Reames" <listmail at philipreames.com>, "Duncan P. N. Exon Smith" > <dexonsmith at apple.com>, "Xinliang David Li" <xinliangli at gmail.com> > Sent: Friday, February 26, 2016 9:01:48 PM > Subject: Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics") > > > I think this will have a much higher cost than my proposal to > constrain how we deduce function attributes (which still fixes > Sanjoy's latest example). > > Specifically, I think this will force us to constrain...

...t; wrote: >> The only optimizations I can think of that are okay are algebraic >> simplifications that don't exploit no-overflow, inbounds or exact > > Why? Can you provide an example using nsw, inbounds, etc.? I think the same case as the general UB applies: void foo(int n) available_externally { if (n s< (n +nsw 1)) abort(); } void bar() { if (< runtine cond always false>) foo(INT_SMAX); } Now foo() can be simplified to "ret void" using the nsw, and the call to foo(INT_SMAX) can be hoisted. This is a problem if we link to an unrefined @foo. -- Sanjoy

...Feb 26, 2016 at 7:08 PM Sanjoy Das <sanjoy at playingwithpointers.com> > wrote: >> >> On Thu, Feb 25, 2016 at 9:59 AM, Sanjoy Das >> <sanjoy at playingwithpointers.com> wrote: >> > Couple of other examples: >> > >> > void @foo(i32* %ptr) available_externally { >> > %discard = load i32, i32* %ptr >> > } >> > void bar() { >> > call @foo(i32* %x) >> > } >> > >> > ==> >> > >> > void @foo(i32* %ptr) available_externally { >> > } >> > v...

On Thu, Feb 25, 2016 at 10:40 PM Justin Bogner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> writes: > > On Thu, Feb 25, 2016 at 6:35 PM, Duncan P. N. Exon Smith > > <dexonsmith at apple.com> wrote: > >>> // In C > >>> void foo() { > >>> int c; > >>>

...lvm-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 expression certain semantic > properties guard intrinsics will have. > > Let's start with an example that shows that we have a problem (direct > copy/paste from the guard intrinsics thread). Say we have: > > ``` > void foo() available_externally { >...

...ed reference for an "inline __attribute__((always_inline))" function. Libc++ relies on the compiler never doing that - it has lots of functions in the headers marked this way and does _not_ export them from libc++.so. Current implementation in clang emits alwaysinline+inline functions as available_externally definitions. The inliner is an SCC pass, and as such it does not process unreachable functions at all. This means that AlwaysInliner may leave some alwaysinline functions not inlined. If such function has an available_externally linkage, it is not emitted into the binary, and all calls to it are...

...m-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 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, com...

...lways_inline))" function. Libc++ relies on the > > compiler never doing that - it has lots of functions in the headers > > marked this way and does _not_ export them from libc++.so. > > > > Current implementation in clang emits alwaysinline+inline functions as > > available_externally definitions. The inliner is an SCC pass, and as > > such it does not process unreachable functions at all. This means that > > AlwaysInliner may leave some alwaysinline functions not inlined. If > > such function has an available_externally linkage, it is not emitted > > i...