search for: lpic0

Hi Rafael, Yes, merging gv prevents linker to do garbage collection. Should it be implemented as a peephole pass? If we do it too early, the distance between GVs are not fixed yet. PS: Below is the GCC output with "extern" hidden: ldr r2, .L2 stmfd sp!, {r3, lr} .save {r3, lr} .LPIC0: add r0, pc, r2 bl _Z4initPv(PLT) ldr r1, .L2+4 .LPIC1: add r0, pc, r1 bl _Z4initPv(PLT) ldr r0, .L2+8 .LPIC2: add r0, pc, r0 ldmfd sp!, {r3, lr} b _Z4initPv(PLT) .L3: .align 2 .L2: .word g0-(.LPIC0+8) .word g1-(.LPIC1+8) .word g2-(.LPIC2+8) Thanks, Weiming Qualcomm Innovation Center...

...&g2); } Clang will emit 1 GOT entry for each GV and 2 instructions to get the address: ldr r0, .LCPI0_2 add r0, r0, r4 bl _Z4initPv(PLT) GCC does this only for the first GV. The rest GV address are computed directly: ldr r4, .L2 .LPIC0: add r4, pc, r4 è get &g0 via GOT_PC Relative mov r0, r4 bl _Z4initPv(PLT) add r0, r4, #400 è get &g1 bl _Z4initPv(PLT) add r0, r4, #800 è get &g2 ldmfd sp!, {r4, lr} b _Z4ini...

>> Any thoughs? > > I'm now struggling to see how GCC justifies it. What if a different > translation-unit declared those variables in a different order? I also > can't get the same behaviour here, do you have a more complete > command-line? Ah, I see; the translation-unit that does the optimisation needs to have them as a definition (i.e. "= {0}") rather