search for: globalobjects

> 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 "fix...

...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 !ra...

...ata load/store must be generated. The existing predicates in SectionKind may be modified to use the underlying Kind (AND-ing with 0x7f), so existing ISel behaviors are mostly unchanged. The proposed target-independent small data classification has 2 usage avenues depending on the context: For all GlobalObjects: 1. Pass GlobalObject to target-independent TargetLoweringObjectFile::isGlobalInSmallSection. If it's a declaration, make a virtual call to a new method named TargetLoweringObjectFile::isGlobalInSmallSectionKind (doing target-specific scrutiny) and return the result early. 2. Pass...

...be generated. The existing predicates in SectionKind may be modified to use the underlying Kind (AND-ing with 0x7f), so existing ISel behaviors are mostly unchanged. > > The proposed target-independent small data classification has 2 usage avenues depending on the context: > > For all GlobalObjects: > > 1. Pass GlobalObject to target-independent > TargetLoweringObjectFile::isGlobalInSmallSection. If it's a > declaration, make a virtual call to a new method named > TargetLoweringObjectFile::isGlobalInSmallSectionKind (doing > target-specific scrutiny) and r...

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

...nd may be > > modified to use the underlying Kind (AND-ing with 0x7f), so > > existing ISel behaviors are mostly unchanged. > > > > The proposed target-independent small data classification has 2 > > usage avenues depending on the context: > > > > For all GlobalObjects: > > > > 1. Pass GlobalObject to target-independent > > TargetLoweringObjectFile::isGlobalInSmallSection. If it's a > > declaration, make a virtual call to a new method named > > TargetLoweringObjectFile::isGlobalInSmallSectionKind (doing > > tar...

I was working on https://reviews.llvm.org/D81911 to try and fix https://bugs.llvm.org/show_bug.cgi?id=46340 . Through the review process we happened upon a design limitation or perhaps a potential mis-modelling of GlobalIFunc in the IR object hierarchy, which leads to some problems in LTO flows. To summarize, as it currently stands (and in the hopes of faithfully representing the conclusions of

> * Calling getBaseObject() on a GlobalIFunc returns its resolver function. I still don't understand how 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

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

...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, because they may shadow other variables. For example: > > int i; > void f() { > stati...

Hi, Got everything built but am now experiencing new errors on making the symbol tables and on 'make check'. Here's the errors I am experiencing :- Aaron Gray at AMD-LAPTOP-1 /usr/llvm-gcc/lib $ ls gcc libdummy.a libiberty.a libstdc++.a libsupc++.la libc.a libgcc.a libm.a libstdc++.la libtrace.a libcrtend.a libgcsemispace.a

Does not look like the demangle test worked anyway :( And 'make check' :- $ make check make[1]: Entering directory `/usr/build/llvm-gcc/gcc' (rootme=`${PWDCMD-pwd}`; export rootme; \ srcdir=`cd /usr/cfrontend/src/gcc; ${PWDCMD-pwd}` ; export srcdir ; \ cd testsuite; \ EXPECT=expect ; export EXPECT ; \ if [ -f ${rootme}/../expect/expect ] ; then \ TCL_LIBRARY=`cd

...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 explicit section, this behavior needs to be disabled. (1.3) Items 1.1 and 1.2 assume that the linker provides linker script information to LTO. They should therefore not be the default behavior, but be guarded under a clang flag, e.g. "-flto-ls", which is passed in addition...

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

Aaron, Could you send me the libiberty.a file? Please gzip it. I would like to make sure this isn't an llvm-ranlib bug. Thanks, Reid. On Thu, 2005-05-19 at 15:36 +0100, Aaron Gray wrote: > Hi, > > Got everything built but am now experiencing new errors on making the > symbol tables and on 'make check'. > > Here's the errors I am experiencing :- > >

Okay, this I have no clue about. I've never done "make check" on llvm- gcc. I thought you meant "make check" on LLVM. You're into "new territory". Reid. On Thu, 2005-05-19 at 16:07 +0100, Aaron Gray wrote: > Does not look like the demangle test worked anyway :( > And 'make check' :- > > $ make check >

Hi all, The bitset metadata currently used in LLVM has a few problems: 1. It has the wrong name. The name "bitset" refers to an implementation detail of one use of the metadata (i.e. its original use case, CFI). This makes it harder to understand, as the name makes no sense in the context of virtual call optimization. 2. It is represented using a global named metadata node, rather than

...ect. 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 explicit section, this > behavior needs to be disabled. > > (1.3) Items 1.1 and 1.2 assume that the linker provides linker script > information to LTO. They should therefore not be the default behavior, but > be > guarded under a clang flag, e.g. "-flto-ls",...

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: