[LLVMdev] How to tell whether a GlobalValue is user-defined

[Bob Wilson]

> On Aug 21, 2014, at 4:32 PM, Akira Hatanaka <ahatanak at gmail.com> wrote:
> 
> Is there a way to distinguish between GlobalValues that are user-defined and those that are compiler-defined? I am looking for a function that I can use to tell if a GlobalValue is user-defined , something like "GlobalValue::isUserDefined", which returns true for user-defined GlobalValue.
> 
> I'm trying to make changes to prevent llvm from placing user-defined constant arrays in the merge able constant sections. Currently, clang places 16-byte constant arrays that are marked "unnamed_addr" into __literal16 for macho (see following example).
> 
> $ cat test1.c
> static const int s_dashArraysSize1[4] = {2, 2, 4, 6};
> 
> int foo1(int a) {
>   return s_dashArraysSize1[a]; 
> }
> 
> $ clang test1.c -S -O3 -o - | tail -n 10
> 	.section	__TEXT,__literal16,16byte_literals
> 	.align	4                       ## @s_dashArraysSize1
> _s_dashArraysSize1:
> 	.long	2                       ## 0x2
> 	.long	2                       ## 0x2
> 	.long	4                       ## 0x4
> 	.long	6                       ## 0x6
> 
> 
> This is not desirable because macho linker wasn't originally designed to handle user-defined symbols in those sections and having to handle them complicates the linker. Also, there is no benefit in doing so, since the linker currently doesn't try to merge user-defined variables anyway.

I would also appreciate opinions on whether this issue is relevant for other platforms. In general, should we put user-defined symbols into literal sections?

In Akira’s example above, GlobalOpt is checking that the variable does not have its address taken and marking them it unnamed_addr. Even if that is a legal optimization, it may cause problems, e.g., for debugging, if the linker removes the symbol. I don’t know whether other linkers will keep all the symbols in literal sections or not. I think you could also make a reasonable argument that we don’t guarantee that the variable will remain visible when debugging optimized code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140821/080a4269/attachment.html>