<div dir="ltr"><div>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.</div><div><br></div>
<div>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.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 1, 2014 at 5:27 AM, Jonas Maebe <span dir="ltr"><<a href="mailto:jonas.maebe@elis.ugent.be" target="_blank">jonas.maebe@elis.ugent.be</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Is there a way in llvm IR to emit multiple data elements within a single compilation unit that<br>
a) are guaranteed to appear sequentially in the final binary (in the order they appear in the llvm IR), and<br>
b) will be removed on an individual basis by the optimizers and/or linker in case they are not referenced from anywhere<br>
?<br>
<br>
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.<br>

<br>
Example:<br>
<br>
***<br>
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-<u></u>i16:16:16-i32:32:32-i64:64:64-<u></u>f32:32:32-f64:64:64-v64:64:64-<u></u>v128:128:128-a0:0:64-s0:64:64-<u></u>f80:128:128-n8:16:32:64-S128"<br>
target triple = "x86_64-pc-linux-gnu"<br>
<br>
define i32 @main() {<br>
  %1 = getelementptr [2 x i8]* @arr1, i64 0, i32 0<br>
  %2 = load i8* %1<br>
  %3 = zext i8 %2 to i32<br>
  ret i32 %3<br>
}<br>
<br>
@arr1 = appending global [2 x i8] [<br>
   i8 1,<br>
   i8 2<br>
], section "mytest"<br>
<br>
@arr2 = appending global [2 x i8] [<br>
   i8 3,<br>
   i8 4<br>
], section "mytest"<br>
***<br>
<br>
Since @arr2 is not referenced, I would like it to not appear in the final binary, but "clang -fdata-sections" generates:<br>
<br>
***<br>
        .type   arr1,@object            # @arr1<br>
        .section        mytest,"aw",@progbits<br>
        .globl  arr1<br>
arr1:<br>
        .ascii  "\001\002"<br>
        .size   arr1, 2<br>
<br>
        .type   arr2,@object            # @arr2<br>
        .globl  arr2<br>
arr2:<br>
        .ascii  "\003\004"<br>
        .size   arr2, 2<br>
***<br>
<br>
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?<br>

<br>
Thanks,<br>
<br>
<br>
Jonas<br>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div>