Andrew Kelley via llvm-dev
2017-Apr-24 18:55 UTC
[llvm-dev] why do undefined globals end up in .data instead of .bss?
On Mon, Apr 24, 2017 at 2:53 PM, Friedman, Eli <efriedma at codeaurora.org> wrote:> On 4/23/2017 10:10 AM, Andrew Kelley via llvm-dev wrote: > >> Here is a module: >> >> @vals = internal unnamed_addr global [20000000 x i32] undef, align 4 >> >> LLVM puts the global in the .data section, and results in a 77MB .o file >> of mostly zeroes. Why does this variable not go in the .bss section? >> >> > I think it's just an oversight; it doesn't matter for clang because it > never emits globals like that. See TargetLoweringObjectFile::getKindForGlobal > for the relevant logic.I see, thanks. Would a patch be welcome which changed this behavior? Or I suppose I could emit zeroinitializer instead of undef. But it seems like undef is the more correct value. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170424/e64f3701/attachment.html>
Friedman, Eli via llvm-dev
2017-Apr-24 19:05 UTC
[llvm-dev] why do undefined globals end up in .data instead of .bss?
On 4/24/2017 11:55 AM, Andrew Kelley wrote:> > > On Mon, Apr 24, 2017 at 2:53 PM, Friedman, Eli > <efriedma at codeaurora.org <mailto:efriedma at codeaurora.org>> wrote: > > On 4/23/2017 10:10 AM, Andrew Kelley via llvm-dev wrote: > > Here is a module: > > @vals = internal unnamed_addr global [20000000 x i32] undef, > align 4 > > LLVM puts the global in the .data section, and results in a > 77MB .o file of mostly zeroes. Why does this variable not go > in the .bss section? > > > I think it's just an oversight; it doesn't matter for clang > because it never emits globals like that. See > TargetLoweringObjectFile::getKindForGlobal for the relevant logic. > > > I see, thanks. Would a patch be welcome which changed this behavior? > Or I suppose I could emit zeroinitializer instead of undef. But it > seems like undef is the more correct value. >Sure, patch welcome. -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170424/d9eff130/attachment.html>
Tobias Edler von Koch via llvm-dev
2017-Apr-25 20:41 UTC
[llvm-dev] why do undefined globals end up in .data instead of .bss?
On 04/24/2017 01:55 PM, Andrew Kelley via llvm-dev wrote:> I see, thanks. Would a patch be welcome which changed this behavior? > Or I suppose I could emit zeroinitializer instead of undef. But it > seems like undef is the more correct value.Are you producing these undef values yourself (in a pass/fronted)? Can you elaborate a little on why you think "undef" is the correct value? Inside LLVM, undef essentially means "any value we choose". The language reference has a section on this. It would be entirely correct if we emitted all 1s instead of all 0s for undef. If you really want it to be .bss, zeroinitializer seems to be the better choice. Tobias -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170425/d1bf905e/attachment.html>
Tim Northover via llvm-dev
2017-Apr-25 20:44 UTC
[llvm-dev] why do undefined globals end up in .data instead of .bss?
On 25 April 2017 at 13:41, Tobias Edler von Koch via llvm-dev <llvm-dev at lists.llvm.org> wrote:> It would be entirely correct if we emitted all 1s > instead of all 0s for undef. If you really want it to be .bss, > zeroinitializer seems to be the better choice.It sounded like he didn't care what the actual data was, just that it didn't consume space in the object file. Tim.
Andrew Kelley via llvm-dev
2017-Apr-25 20:48 UTC
[llvm-dev] why do undefined globals end up in .data instead of .bss?
On Tue, Apr 25, 2017 at 4:41 PM, Tobias Edler von Koch < tobias at codeaurora.org> wrote:> On 04/24/2017 01:55 PM, Andrew Kelley via llvm-dev wrote: > > I see, thanks. Would a patch be welcome which changed this behavior? Or I > suppose I could emit zeroinitializer instead of undef. But it seems like > undef is the more correct value. > > > Are you producing these undef values yourself (in a pass/fronted)? >Yes, frontend> Can you elaborate a little on why you think "undef" is the correct value? > Inside LLVM, undef essentially means "any value we choose". The language > reference has a section on this. It would be entirely correct if we emitted > all 1s instead of all 0s for undef. If you really want it to be .bss, > zeroinitializer seems to be the better choice. >Yes, any value would be semantically correct. What I am communicating to LLVM is "any value will be fine here" which means that LLVM can do whatever it wants here to achieve better performance, compile time speed, smaller object size, or another goal that I have not thought of. And in this email thread I am suggesting that LLVM should probably choose the smaller object size goal in this situation, choose 0 for the value, and put it in .bss.> > > Tobias > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project. > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170425/89dd08e2/attachment.html>