search for: derefinement

Hey all, I'm working on adding interprocedural FunctionAttrs optimization ( http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/FunctionAttrs.cpp) to ThinLTO so it does something similar to what LTO is doing ( https://bugs.llvm.org/show_bug.cgi?id=33648). I've hit a problem with how the FunctionAttrs optimization expects linkage types. In ThinLTO since the linkage type is set to External or

...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 hasExactDefinition &...

...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 marked...

...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 marked al...

...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 bounda...

...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 callsite...

...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 callsit...

...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 inexa...

...; 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...

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