search for: derefin

...e functionattr optimizations that LTO can (since LTO is able to convert everything to Internal). This is a problem because every functionattr optimization expects an exact definition by calling hasExactDefinition (http://llvm-cs.pcc.me.uk/ include/llvm/IR/GlobalValue.h#387) which doesn't want a derefined function (mayBeDerefined http://llvm-cs.pcc.me.uk/include/llvm/IR/GlobalValue.h#119). According to the current definition, an AvailableExternally function could be derefined so hasExactDefinition fails. Does anyone have any ideas on how to make a function with External/AvailableExternally linkag...

...xternally is concerned, preventing FunctionAttrs on them is by design and I'm not sure if there is anything in ThinLTO to fix that (assuming that the functions are, in fact, available_externally). There is some background information on this issue at https://www.playingwithpointers.com/ipo-and-derefinement.html -- Sanjoy >> it is unable to apply any of the functionattr optimizations that LTO can >> (since LTO is able to convert everything to Internal). This is a problem >> because every functionattr optimization expects an exact definition by >> calling hasExactDefinit...

...missing in new pass manager -- this one will get fixed in the near future *Untrusted Declarations* In several cases, we check hasExactDefinition before checking properties of the function declaration (such as return type).  To my knowledge, facts on declarations are valid even in the place of derefinement.  This results in the analysis being unnecessarily conservative around external declarations. *AlwaysInline and hasExactDefinition* I believe, but have not fully thought through, that it is legal to IPO across an inexact definition boundary if a particularly callsite or declaration is ma...

...y -- useful for AA speculatable - useful for speculation, LICM, PRE, etc... Untrusted Declarations In several cases, we check hasExactDefinition before checking properties of the function declaration (such as return type). To my knowledge, facts on declarations are valid even in the place of derefinement. This results in the analysis being unnecessarily conservative around external declarations. AlwaysInline and hasExactDefinition I believe, but have not fully thought through, that it is legal to IPO across an inexact definition boundary if a particularly callsite or declaration is mark...

...E, etc... >> >> >> >> Untrusted Declarations >> >> In several cases, we check hasExactDefinition before checking properties of >> the function declaration (such as return type). To my knowledge, facts on >> declarations are valid even in the place of derefinement. This results in >> the analysis being unnecessarily conservative around external declarations. >> >> >> AlwaysInline and hasExactDefinition >> >> I believe, but have not fully thought through, that it is legal to IPO >> across an inexact definition b...

...le - useful for speculation, LICM, PRE, etc... > *Untrusted Declarations* > > In several cases, we check hasExactDefinition before checking > properties of the function declaration (such as return type). To my > knowledge, facts on declarations are valid even in the place of > derefinement.  This results in the analysis being unnecessarily > conservative around external declarations. > > *AlwaysInline and hasExactDefinition* > > I believe, but have not fully thought through, that it is legal to IPO > across an inexact definition boundary if a particularly cal...

...useful for speculation, LICM, PRE, etc... > > > > Untrusted Declarations > > In several cases, we check hasExactDefinition before checking properties of > the function declaration (such as return type). To my knowledge, facts on > declarations are valid even in the place of derefinement. This results in > the analysis being unnecessarily conservative around external declarations. > > > AlwaysInline and hasExactDefinition > > I believe, but have not fully thought through, that it is legal to IPO > across an inexact definition boundary if a particularly ca...

...gt;> >> >> Untrusted Declarations >> >> In several cases, we check hasExactDefinition before checking properties >> of >> the function declaration (such as return type). To my knowledge, facts >> on >> declarations are valid even in the place of derefinement. This results >> in >> the analysis being unnecessarily conservative around external >> declarations. >> >> >> AlwaysInline and hasExactDefinition >> >> I believe, but have not fully thought through, that it is legal to IPO >> across an...

...; Untrusted Declarations >>> >>> In several cases, we check hasExactDefinition before checking >>> properties of >>> the function declaration (such as return type).  To my knowledge, >>> facts on >>> declarations are valid even in the place of derefinement. This >>> results in >>> the analysis being unnecessarily conservative around external >>> declarations. >>> >>> >>> AlwaysInline and hasExactDefinition >>> >>> I believe, but have not fully thought through, that it is l...

Problem LLVM's memory model for NonAtomic accesses is generally fairly weak, but explicitly disallows inserting stores that didn't occur in the original program.  This is required for any potentially shared location, but is overkill for any memory location which is provably only accessed by a single thread. My particular motivating example is a single thread private field in our