llvm dev - Aug 2014 - [LLVMdev] Create "appending" section that can be partially dead stripped

Hi,

Is there a way in llvm IR to emit multiple data elements within a  
single compilation unit that
a) are guaranteed to appear sequentially in the final binary (in the  
order they appear in the llvm IR), and
b) will be removed on an individual basis by the optimizers and/or  
linker in case they are not referenced from anywhere
?

Defining them as "appending" puts them all into a single section  
definition, even when compiling with -fdata-sections, so as soon as  
one of the symbols in that section is live, all of them will remain  
live.

Example:

***
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- 
i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64- 
f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"

define i32 @main() {
   %1 = getelementptr [2 x i8]* @arr1, i64 0, i32 0
   %2 = load i8* %1
   %3 = zext i8 %2 to i32
   ret i32 %3
}

@arr1 = appending global [2 x i8] [
    i8 1,
    i8 2
], section "mytest"

@arr2 = appending global [2 x i8] [
    i8 3,
    i8 4
], section "mytest"
***

Since @arr2 is not referenced, I would like it to not appear in the  
final binary, but "clang -fdata-sections" generates:

***
         .type   arr1, at object            # @arr1
         .section        mytest,"aw", at progbits
         .globl  arr1
arr1:
         .ascii  "\001\002"
         .size   arr1, 2

         .type   arr2, at object            # @arr2
         .globl  arr2
arr2:
         .ascii  "\003\004"
         .size   arr2, 2
***

Alternatively, in case the "appending" linkage type implies "this
data
is also accessible via a getelementptr based on other data in that  
same section, and therefore must remain live", is there another way to  
achieve this?

Thanks,


Jonas

What happens if you drop appending linkage?  I think it will just work,
since you are already using a custom section, which will ensure that all
the data appears contiguously in memory.

Although, I do worry about what LLVM's alias analysis will say about
this... I don't think LLVM allows GEPing from one global to another, and at
the end of the day, you'll GEP from an external global representing the
section start through to the elements of the array to section end.


On Fri, Aug 1, 2014 at 5:27 AM, Jonas Maebe <jonas.maebe at elis.ugent.be>
wrote:
> Hi,
>
> Is there a way in llvm IR to emit multiple data elements within a single
> compilation unit that
> a) are guaranteed to appear sequentially in the final binary (in the order
> they appear in the llvm IR), and
> b) will be removed on an individual basis by the optimizers and/or linker
> in case they are not referenced from anywhere
> ?
>
> Defining them as "appending" puts them all into a single section
> definition, even when compiling with -fdata-sections, so as soon as one of
> the symbols in that section is live, all of them will remain live.
>
> Example:
>
> ***
> target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-
> i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-
> v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
> target triple = "x86_64-pc-linux-gnu"
>
> define i32 @main() {
>   %1 = getelementptr [2 x i8]* @arr1, i64 0, i32 0
>   %2 = load i8* %1
>   %3 = zext i8 %2 to i32
>   ret i32 %3
> }
>
> @arr1 = appending global [2 x i8] [
>    i8 1,
>    i8 2
> ], section "mytest"
>
> @arr2 = appending global [2 x i8] [
>    i8 3,
>    i8 4
> ], section "mytest"
> ***
>
> Since @arr2 is not referenced, I would like it to not appear in the final
> binary, but "clang -fdata-sections" generates:
>
> ***
>         .type   arr1, at object            # @arr1
>         .section        mytest,"aw", at progbits
>         .globl  arr1
> arr1:
>         .ascii  "\001\002"
>         .size   arr1, 2
>
>         .type   arr2, at object            # @arr2
>         .globl  arr2
> arr2:
>         .ascii  "\003\004"
>         .size   arr2, 2
> ***
>
> Alternatively, in case the "appending" linkage type implies
"this data is
> also accessible via a getelementptr based on other data in that same
> section, and therefore must remain live", is there another way to
achieve
> this?
>
> Thanks,
>
>
> Jonas
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140801/c2edd85b/attachment.html>

On 01/08/14 19:37, Reid Kleckner wrote:
> What happens if you drop appending linkage?  I think it will just work,
> since you are already using a custom section, which will ensure that all
> the data appears contiguously in memory.
Thanks for the suggestion, but it still puts everything in a single 
.section statement.
> Although, I do worry about what LLVM's alias analysis will say about
> this... I don't think LLVM allows GEPing from one global to another,
and
> at the end of the day, you'll GEP from an external global representing
> the section start through to the elements of the array to section end.
That's true and an interesting point. However, wouldn't that mean that 
"appending" linkage and "section" globals in general are
completely
unusable from llvm IR and would only be safely usable from inline 
assembler or code not compiled by llvm? (unless you don't access such 
data as a contiguous block, but I guess that doesn't happen very often)


Jonas