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

Bob Wilson
Fri, 22 Aug 2014 00:48:00 -0000

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