Hi, I'm trying to do a proof of concept of compiling some code down to a very simple runtime that doesn't provide support for zeroinitialize. If I run the below code through llc: ; ModuleID = '.\t.bc' target datalayout = "e-m:w-p:32:32-i64:64-f80:32-n8:16:32-S32" target triple = "i686-pc-windows-gnu" @_ZN3Foo11ZeroAndZeroE = global [2 x i32] [i32 0, i32 0], align 4 !llvm.ident = !{!0} !0 = !{!"clang version 3.6.0 (tags/RELEASE_360/final)"} It turns into this: ; ModuleID = '.\t.ll' target datalayout = "e-m:w-p:32:32-i64:64-f80:32-n8:16:32-S32" target triple = "i686-pc-windows-gnu" @_ZN3Foo11ZeroAndZeroE = global [2 x i32] zeroinitializer, align 4 !llvm.ident = !{!0} !0 = !{!"clang version 3.6.0 (tags/RELEASE_360/final)"} My question is where is this transform happening - it looks like it's a byproduct of parsing the ll file which was super surprising to me. And second is there a know what to circumvent this? For my app I just want the zero'd space in the section so I can copy it into memory. Thanks, -R -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150721/b55d4235/attachment.html>
On Tue, Jul 21, 2015 at 1:31 PM, Russell Hadley <rhadley at microsoft.com> wrote:> Hi, > > > > I’m trying to do a proof of concept of compiling some code down to a very > simple runtime that doesn’t provide support for zeroinitialize. If I run > the below code through llc: > > > > ; ModuleID = '.\t.bc' > > target datalayout = "e-m:w-p:32:32-i64:64-f80:32-n8:16:32-S32" > > target triple = "i686-pc-windows-gnu" > > > > @_ZN3Foo11ZeroAndZeroE = global [2 x i32] [i32 0, i32 0], align 4 > > > > !llvm.ident = !{!0} > > > > !0 = !{!"clang version 3.6.0 (tags/RELEASE_360/final)"} > > > > It turns into this: > > > > ; ModuleID = '.\t.ll' > > target datalayout = "e-m:w-p:32:32-i64:64-f80:32-n8:16:32-S32" > > target triple = "i686-pc-windows-gnu" > > > > @_ZN3Foo11ZeroAndZeroE = global [2 x i32] zeroinitializer, align 4 > > > > !llvm.ident = !{!0} > > > > !0 = !{!"clang version 3.6.0 (tags/RELEASE_360/final)"} > > > > My question is where is this transform happening – it looks like it’s a > byproduct of parsing the ll file which was super surprising to me. >This is a natural result of the IR constant folder. It isn't an optimization per-se, it is part of the mechanism which canonicalizes constants.> And second is there a know what to circumvent this? >It is impossible to disable it.> For my app I just want the zero’d space in the section so I can copy it > into memory. >I don't quite follow. @_ZN3Foo11ZeroAndZeroE will be in the .bss section section and will end up in memory. Do you need it in some other section?> > > Thanks, > > > > -R > > _______________________________________________ > 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/20150721/34dcefbb/attachment.html>
Hi Russel, On 21 July 2015 at 13:31, Russell Hadley <rhadley at microsoft.com> wrote:> My question is where is this transform happening – it looks like it’s a > byproduct of parsing the ll file which was super surprising to me.It's not even a transformation. It's just a shorthand used for printing out (and reading in) a constant 0. What you want to do (well, what you think you want to do) is prevent LLVM from putting any 0 data in a special section when compiling.> And second is there a know what to circumvent this? For my app I just want the > zero’d space in the section so I can copy it into memory.This is probably better handled at the linker level, but for hacking purposes there does seem to be an llc option to override the choice to use automatic zero-fill: -nozero-initialized-in-bss. I've never used it, but it may help for some quick tests. Cheers. Tim.
Thanks the .bss trick was part of it. I had another wire crossed but I've got it straightened now. -----Original Message----- From: Tim Northover [mailto:t.p.northover at gmail.com] Sent: Tuesday, July 21, 2015 1:46 PM To: Russell Hadley Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] How to not zeroinitialize array Hi Russel, On 21 July 2015 at 13:31, Russell Hadley <rhadley at microsoft.com> wrote:> My question is where is this transform happening – it looks like it’s > a byproduct of parsing the ll file which was super surprising to me.It's not even a transformation. It's just a shorthand used for printing out (and reading in) a constant 0. What you want to do (well, what you think you want to do) is prevent LLVM from putting any 0 data in a special section when compiling.> And second is there a know what to circumvent this? For my app I just > want the zero’d space in the section so I can copy it into memory.This is probably better handled at the linker level, but for hacking purposes there does seem to be an llc option to override the choice to use automatic zero-fill: -nozero-initialized-in-bss. I've never used it, but it may help for some quick tests. Cheers. Tim.
Maybe Matching Threads
- [LLVMdev] [3.6 Release] Release Candidate 2 available
- [LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2
- [LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2
- Substitute instruction with a jump to a library code
- [LLVMdev] GCC compatibility code coverage issue .