search for: globalobject

> On Oct 24, 2016, at 1:07 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Oct 10, 2016 at 8:12 PM, Peter Collingbourne <peter at pcc.me.uk <mailto:peter at pcc.me.uk>> wrote: > The specific change I have in mind is to allow !range metadata on GlobalObjects. This would > be similar to existing !range metadata, but it would apply to the "address" of the attached GlobalObject, rather than any value loaded from it. Its presence on a GlobalObject would also imply that the address of the GlobalObject is "fixed" at link time. >...

On 10/24/2016 1:07 PM, Peter Collingbourne via llvm-dev wrote: > On Mon, Oct 10, 2016 at 8:12 PM, Peter Collingbourne <peter at pcc.me.uk > <mailto:peter at pcc.me.uk>> wrote: > > The specific change I have in mind is to allow !range metadata on > GlobalObjects. This would > be similar to existing !range metadata, but it would apply to the > "address" of the attached GlobalObject, rather than any value > loaded from it. Its presence on a GlobalObject would also imply > that the address of the GlobalObject is "fi...

...c.f. https://reviews.llvm.org/D19844). The latter case in particular would seem to indicate that a representational change is required for correctness to distinguish references to absolute symbols from references to regular symbols. The specific change I have in mind is to allow !range metadata on GlobalObjects. This would be similar to existing !range metadata, but it would apply to the "address" of the attached GlobalObject, rather than any value loaded from it. Its presence on a GlobalObject would also imply that the address of the GlobalObject is "fixed" at link time. Alongside !r...

...nds to the `-G <bytes>` flag so the user can define a cutoff size other than 8 (or 0 to disable small data altogether). It seems the Hexagon and Lanai targets duplicate much of the IsGlobalInSmallSection handling from the MIPS target, but perform the same basic classification tasks: 1. Pass GlobalObject to target-declared IsGlobalInSmallSection. If it's a declaration, skip to step 4. 2. Pass GlobalObject to target-independent TargetLoweringObjectFile::getKindForGlobal. 3. Ensure the returned SectionKind is Data, BSS or Common. 4. Pass GlobalObject to target-specific IsGlobalInSmallSectio...

...ytes>` flag so the user can define a cutoff size other than 8 (or 0 to disable small data altogether). > > It seems the Hexagon and Lanai targets duplicate much of the IsGlobalInSmallSection handling from the MIPS target, but perform the same basic classification tasks: > > 1. Pass GlobalObject to target-declared IsGlobalInSmallSection. > If it's a declaration, skip to step 4. > 2. Pass GlobalObject to target-independent > TargetLoweringObjectFile::getKindForGlobal. > 3. Ensure the returned SectionKind is Data, BSS or Common. > 4. Pass GlobalObject to target-spe...

...er Collingbourne <peter at pcc.me.uk <mailto:peter at pcc.me.uk>> wrote: >> >> On Mon, Oct 10, 2016 at 8:12 PM, Peter Collingbourne <peter at pcc.me.uk <mailto:peter at pcc.me.uk>> wrote: >> The specific change I have in mind is to allow !range metadata on GlobalObjects. This would >> be similar to existing !range metadata, but it would apply to the "address" of the attached GlobalObject, rather than any value loaded from it. Its presence on a GlobalObject would also imply that the address of the GlobalObject is "fixed" at link time. &gt...

...e other than 8 (or 0 to disable small data > > altogether). > > > > It seems the Hexagon and Lanai targets duplicate much of the > > IsGlobalInSmallSection handling from the MIPS target, but perform > > the same basic classification tasks: > > > > 1. Pass GlobalObject to target-declared IsGlobalInSmallSection. > > If it's a declaration, skip to step 4. > > 2. Pass GlobalObject to target-independent > > TargetLoweringObjectFile::getKindForGlobal. > > 3. Ensure the returned SectionKind is Data, BSS or Common. > > 4. Pass Glo...

...s resolver are *not* interchangeable: at the interface level, they have different signatures (conceptually, the IFunc has the same signature of the function pointer that the resolver potentially returns, not of the resolver itself). * It makes sense for the IFunc to be its own base object (which is GlobalObject-like-behavior), but type-hierarchy-wise it can't. This is because GlobalIFunc derives from GlobalIndirectSymbol which derives directly from GlobalValue, and therefore it is not a GlobalObject. Would it make sense for GlobalIFunc to derive from GlobalObject instead of GlobalIndirectSymbol? If s...

...it can happen looking to the code ( https://github.com/llvm/llvm-project/blob/master/llvm/lib/IR/Globals.cpp#L430). I believe it should return nullptr (the same as if you call it from GlobalAlias that refers to GlobalIFunc). I don't have a strong opinion here because deriving GlobalIFunc from GlobalObject does make some sense. At the same time from implementation point of view there were lots of similarities between GlobalAlias and GlobalIFunc (in the most case they should be handled identically or very similarly). getBaseObject method in initial implementation belonged to GlobalAlias only. David mo...

...>> >> On 10/24/2016 1:07 PM, Peter Collingbourne via llvm-dev wrote: >> >> On Mon, Oct 10, 2016 at 8:12 PM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >>> >>> The specific change I have in mind is to allow !range metadata on >>> GlobalObjects. This would >>> be similar to existing !range metadata, but it would apply to the >>> "address" of the attached GlobalObject, rather than any value loaded from >>> it. Its presence on a GlobalObject would also imply that the address of the >>> GlobalOb...

...aph, why do you need to keep a compile unit (and the associated retained informations) if nothing in the IR (transitively) points to this compile unit? (i.e. it is unreachable from the IR) -- Mehdi > We will also need a story for preserving DIGlobalVariables that are constants and have their GlobalObject optimized away. We can definitely remove all the global variables that are referenced from GlobalObjects’ !dbg attachments from the DICompileUnit’s list of globals, but we will need to retain all constants. Really, we should also retain all non-constant globals that had their storage optimized away...

...11EEvv out: void abs<(int)11>() exp: void abs<11>() FAIL at line 2804, style gnu-v3: in: _ZN1AIfEcvT_IiEEv out: A<float>::operator float<int>() exp: A<float>::operator int<int>() FAIL at line 2816, style gnu-v3: in: _ZN5libcw5debug13cwprint_usingINS_9_private_12GlobalObjectEEENS0_17cwprint_ using_tctIT_EERKS5_MS5_KFvRSt7ostreamE out: (null) exp: libcw::debug::cwprint_using_tct<libcw::_private_::GlobalObject> libcw::debu g::cwprint_using<libcw::_private_::GlobalObject>(libcw::_private_::GlobalObject const&, void (libcw::_private_::GlobalObject::*)(std::...

...id abs<(int)11>() exp: void abs<11>() FAIL at line 2804, style gnu-v3: in: _ZN1AIfEcvT_IiEEv out: A<float>::operator float<int>() exp: A<float>::operator int<int>() FAIL at line 2816, style gnu-v3: in: _ZN5libcw5debug13cwprint_usingINS_9_private_12GlobalObjectEEENS0_17cwprint_ using_tctIT_EERKS5_MS5_KFvRSt7ostreamE out: (null) exp: libcw::debug::cwprint_using_tct<libcw::_private_::GlobalObject> libcw::debu g::cwprint_using<libcw::_private_::GlobalObject>(libcw::_private_::GlobalObject const&, void (libcw::_private_::GlobalObject...

...rules; however, bitcode does not naturally contain section names for symbols (except for those with explicit section attributes). (1.1) For this reason, we run a pass immediately prior to bitcode emission that initializes a minimal backend and uses the backend to obtain a section name for each GlobalObject. The section name is then stored in the GlobalObject's explicit section attribute. (1.2) ThinLTO currently marks all symbols with explicit sections as "not eligible for import", which is overly conservative when LTO is aware of the linker script. Since all GlobalObjects now have an e...

Hi all, I'd like to add support for metadata attachments for global variables in the same way as we did for functions. Syntax would be pretty simple: @foo = global i32 0, !foo !0, !bar !1 (the extra commas are required to disambiguate from a named metadata on the next line) Benefits: 1) Lets us reverse the DIGlobalVariable -> GlobalVariable edge, which should hopefully clear the way for

...gt; exp: void abs<11>() > FAIL at line 2804, style gnu-v3: > in: _ZN1AIfEcvT_IiEEv > out: A<float>::operator float<int>() > exp: A<float>::operator int<int>() > FAIL at line 2816, style gnu-v3: > in: > _ZN5libcw5debug13cwprint_usingINS_9_private_12GlobalObjectEEENS0_17cwprint_ > using_tctIT_EERKS5_MS5_KFvRSt7ostreamE > out: (null) > exp: libcw::debug::cwprint_using_tct<libcw::_private_::GlobalObject> > libcw::debu > g::cwprint_using<libcw::_private_::GlobalObject>(libcw::_private_::GlobalObject > const&, void (libcw::_pr...

...2804, style gnu-v3: > in: _ZN1AIfEcvT_IiEEv > out: A<float>::operator float<int>() > exp: A<float>::operator int<int>() > FAIL at line 2816, style gnu-v3: > in: > _ZN5libcw5debug13cwprint_usingINS_9_private_12GlobalObjectEEENS0_17cwprint_ > using_tctIT_EERKS5_MS5_KFvRSt7ostreamE > out: (null) > exp: > libcw::debug::cwprint_using_tct<libcw::_private_::GlobalObject> libcw::debu > g::cwprint_using<libcw::_private_::GlobalObject>(libcw::_private_::Global...

...tains to, rather than using the "llvm.bitsets" global metadata node as we are doing now. This would be done using the newly introduced capability to attach metadata to global variables (r271348 and r271358). Passes which manipulate globals can easily copy metadata between globals with the GlobalObject::copyMetadata function, which would be taught to understand type metadata. To give an example of how this would look, suppose that we have the following declarations: class A { virtual void f() {} }; class B : public A { virtual void f() {} virtual void g() {} }; The vtables for A and B w...

...ot naturally contain section names for symbols (except for those with > explicit section attributes). > > (1.1) For this reason, we run a pass immediately prior to bitcode emission > that > initializes a minimal backend and uses the backend to obtain a section name > for > each GlobalObject. The section name is then stored in the GlobalObject's > explicit section attribute. > > (1.2) ThinLTO currently marks all symbols with explicit sections as "not > eligible for import", which is overly conservative when LTO is aware of the > linker script. Since all Glo...

Oh, one thing I forgot to mention: ReadOnly objects are also counted as small data globals on PPC (on top of BSS, Data, Common). That's what the r2 base is for (.sdata2, defined to be constant data). 32-bit immediate loads take 2 ops minimum on PPC, so even constant loading benefits from small data. It'd be handy to add a third argument containing what kind would normally be returned: