search for: isstrongdefinitionforlink

...ics. In the below example, the dead load from %p may not have been // eliminated from the linker-chosen copy of f, so replacing %p with undef // in callers may introduce undefined behavior. // // define linkonce_odr void @f(i32* %p) { // %v = load i32 %p // ret void // } if (!Fn.isStrongDefinitionForLinker()) return false; -- Sanjoy

...ay not have > been > // eliminated from the linker-chosen copy of f, so replacing %p with > undef > // in callers may introduce undefined behavior. > // > // define linkonce_odr void @f(i32* %p) { > // %v = load i32 %p > // ret void > // } > if (!Fn.isStrongDefinitionForLinker()) > return false; > > -- Sanjoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160227/d7524a33/attachment-0001.html>

...an't optimize bar(), > including deducing attributes on it. Any reference to bar() is > "final": bar() can't be interposed by the linker. > > I think you should be able to infer attributes (and do IPA in > general on any function that matches > GlobalValue::isStrongDefinitionForLinker()). > I suppose you could have one instance of foo() inline bar() _before_ any optimization, and another instance of foo() call a refined readnone bar. Then replacing the latter with the former will be a problem. -- Sanjoy

...eliminated from the linker-chosen copy of f, so replacing %p with >> undef >> // in callers may introduce undefined behavior. >> // >> // define linkonce_odr void @f(i32* %p) { >> // %v = load i32 %p >> // ret void >> // } >> if (!Fn.isStrongDefinitionForLinker()) >> return false; >> >> -- Sanjoy -- Sanjoy Das http://playingwithpointers.com

...still fail to understand why you can't optimize bar(), including deducing attributes on it. Any reference to bar() is "final": bar() can't be interposed by the linker. I think you should be able to infer attributes (and do IPA in general on any function that matches GlobalValue::isStrongDefinitionForLinker()). -- Mehdi > > -Hal > >> -- >> Mehdi > >>>> In short, it is not clear to me that the number of problematic >>>> optimizations is large (seems likely restricted to things >>>> involving >>>> atomics in practice), &gt...

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 optimized @foo will crash } ;;

Hal Finkel wrote: > That summary needs unnecessarily broad. So far we've learned that: a) There are issues with atomics b) there are issues > with a safe-to-speculate attribute we don't yet have c) there might be issues with 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

----- 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 lists.llvm.org> > Sent: Thursday, February 25, 2016 12:02:16 AM > Subject: Re: [llvm-dev] Possible soundness issue with

> 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