[llvm-dev] RFC: metadata attachments for global variables

[Pete Cooper via llvm-dev]

+1 or attaching metadata to globals.  I’d be curious if we can attach !range to a global representing an enum for example.  But…

Should we care about GlobalMerge for !dbg here?  Currently if we merge globals ‘a’ and ‘b’ in to __merged_global, i guess the DIGlobalVariable’s for ‘a’ and ‘b’ would now both point to the new __merged_global.

If thats the case, then by having the !dbg on the global, we wouldn’t be able to handle this case, unless you allow the !dbg to (optionally) point to a list of DIGlobalVariable’s.

BTW, this isn’t something I think should block this bug, but just wanted to point out that it could be an issue.  MergeFunction’s likely has a similar issue with !dbg on functions and I guess we don’t handle it there either.

Cheers
Pete
> On May 6, 2016, at 2:23 PM, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> +1.  I've seen a couple of cases where metadata on a global would be useful as an optimization hint as well.  
> 
> Philip
> 
> On 05/06/2016 01:17 PM, Peter Collingbourne via llvm-dev wrote:
>> 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 removing the llvm.dbg.cu <http://llvm.dbg.cu/> named metadata node.
>> 
>> 2) Allows for bitset metadata to be attached to globals rather than being represented as a named metadata node. This means that bitset metadata is naturally dropped when globals are dropped, and makes it easier to manipulate bitset metadata and build summaries of bitset definitions.
>> 
>> Comments appreciated.
>> 
>> Thanks,
>> -- 
>> -- 
>> Peter
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160506/5ac3213f/attachment.html>