On May 7, 2010, at 10:02 AM, Aaron Gray wrote:> On 7 May 2010 17:53, Chris Lattner <clattner at apple.com> wrote: > > On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: > >>> This seems counter intuitive to me, I can understand that C assigned that behavior somewhat arbitrarily to uninitialized global variables, but in LLVM there is explicitly a common linkage attribute to get that behavior. Nothing in the llvm language reference indicates the behavior of a global with the 'internal' linkage attribute should change based of the values used to initialize it. >> >> I don't follow. The object file format provides a means for efficiently zero filling a local symbol. The compiler is just using it. What is the problem you're trying to solve here? Since it is not exported out of the .o file (it is local) there whether it is "common" or not is undetectable, we just get a storage optimization. >> >> >> I don't know, I see common and it makes me think that things are getting merged together, but as you say it is local so the fact that its also common becomes irrelevant. In MachO do you just put these into the .bss section? >> > > Macho has a special zerofill directive (targeted at the BSS section) for this. You can see this by running your example like this: > > $ llc t.ll -o - -mtriple=i386-apple-darwin10 > .section __TEXT,__text,regular,pure_instructions > .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 > .section __DATA,__data > _tst2: ## @tst2 > .ascii "\000\001\002\003" > > I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream methods, the latter to deal with dllexports in 'lib/Target/X86/AsmPrinter/AsmPrinter.cpp:569'. > > We also need to sort out COFF TLOF, and get rid of the directive stuff.It looks to me that you should have an Emit method for the .scl, .def, .type, .endef directives. One callback each. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100507/55a24b87/attachment.html>
On 7 May 2010 18:14, Chris Lattner <clattner at apple.com> wrote:> > On May 7, 2010, at 10:02 AM, Aaron Gray wrote: > > On 7 May 2010 17:53, Chris Lattner <clattner at apple.com> wrote: > >> >> On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: >> >> This seems counter intuitive to me, I can understand that C assigned that >>> behavior somewhat arbitrarily to uninitialized global variables, but in LLVM >>> there is explicitly a common linkage attribute to get that behavior. Nothing >>> in the llvm language reference indicates the behavior of a global with the >>> 'internal' linkage attribute should change based of the values used to >>> initialize it. >>> >>> >>> I don't follow. The object file format provides a means for efficiently >>> zero filling a local symbol. The compiler is just using it. What is the >>> problem you're trying to solve here? Since it is not exported out of the .o >>> file (it is local) there whether it is "common" or not is undetectable, we >>> just get a storage optimization. >>> >>> >> I don't know, I see common and it makes me think that things are getting >> merged together, but as you say it is local so the fact that its also common >> becomes irrelevant. In MachO do you just put these into the .bss section? >> >> >> Macho has a special zerofill directive (targeted at the BSS section) for >> this. You can see this by running your example like this: >> >> $ llc t.ll -o - -mtriple=i386-apple-darwin10 >> .section __TEXT,__text,regular,pure_instructions >> .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 >> .section __DATA,__data >> _tst2: ## @tst2 >> .ascii "\000\001\002\003" >> > > I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream > methods, the latter to deal with dllexports in ' > lib/Target/X86/AsmPrinter/AsmPrinter.cpp:569'. > > We also need to sort out COFF TLOF, and get rid of the directive stuff. > > > It looks to me that you should have an Emit method for the .scl, .def, > .type, .endef directives. One callback each. >There is already a MCStreamer::EmitZerofill() is seems to be MachO specific ? 'MCStreamer::EmitCOFFStabs()' ? 'MCStreamer:: EmitASCII()' ? Shall I do these as two separate patches ? Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100507/bba5420b/attachment.html>
> > 'MCStreamer::EmitCOFFStabs()' ? >Sorry, its not STABS, something more like, 'MCStreamer:: EmitCOFFType(uint8_t storageClass, uint8_t type)'> 'MCStreamer:: EmitASCII()' ? >And 'MCStreamer:: EmitASCII(uint8_t *string)' or should we use Twine ? Shall I do these as two separate patches ?>Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100507/ad17ab73/attachment.html>
On Fri, May 7, 2010 at 10:14 AM, Chris Lattner <clattner at apple.com> wrote:> > On May 7, 2010, at 10:02 AM, Aaron Gray wrote: > > On 7 May 2010 17:53, Chris Lattner <clattner at apple.com> wrote: > >> >> On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: >> >> This seems counter intuitive to me, I can understand that C assigned that >>> behavior somewhat arbitrarily to uninitialized global variables, but in LLVM >>> there is explicitly a common linkage attribute to get that behavior. Nothing >>> in the llvm language reference indicates the behavior of a global with the >>> 'internal' linkage attribute should change based of the values used to >>> initialize it. >>> >>> >>> I don't follow. The object file format provides a means for efficiently >>> zero filling a local symbol. The compiler is just using it. What is the >>> problem you're trying to solve here? Since it is not exported out of the .o >>> file (it is local) there whether it is "common" or not is undetectable, we >>> just get a storage optimization. >>> >>> >> I don't know, I see common and it makes me think that things are getting >> merged together, but as you say it is local so the fact that its also common >> becomes irrelevant. In MachO do you just put these into the .bss section? >> >> >> Macho has a special zerofill directive (targeted at the BSS section) for >> this. You can see this by running your example like this: >> >> $ llc t.ll -o - -mtriple=i386-apple-darwin10 >> .section __TEXT,__text,regular,pure_instructions >> .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 >> .section __DATA,__data >> _tst2: ## @tst2 >> .ascii "\000\001\002\003" >> > > I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream > methods, the latter to deal with dllexports in ' > lib/Target/X86/AsmPrinter/AsmPrinter.cpp:569'. > > We also need to sort out COFF TLOF, and get rid of the directive stuff. > > > It looks to me that you should have an Emit method for the .scl, .def, > .type, .endef directives. One callback each. > > -Chris >I've had included a EmitCOFFSymbolDef in MCStreamer to replace the EmitRawText that was handling this, seem to me it would be easier to have a single call given the restrictions on their use. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100507/5050ce6b/attachment.html>
On May 7, 2010, at 11:42 AM, Nathan Jeffords wrote:>> $ llc t.ll -o - -mtriple=i386-apple-darwin10 >> .section __TEXT,__text,regular,pure_instructions >> .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 >> .section __DATA,__data >> _tst2: ## @tst2 >> .ascii "\000\001\002\003" >> >> I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream methods, the latter to deal with dllexports in 'lib/Target/X86/AsmPrinter/AsmPrinter.cpp:569'. >> >> We also need to sort out COFF TLOF, and get rid of the directive stuff. > > It looks to me that you should have an Emit method for the .scl, .def, .type, .endef directives. One callback each. > > -Chris > > I've had included a EmitCOFFSymbolDef in MCStreamer to replace the EmitRawText that was handling this, seem to me it would be easier to have a single call given the restrictions on their use.Sure, whatever you guys think is best. It is also very reasonable to add new enums to MCSymbolAttr if EmitSymbolAttribute is the right callback for these. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100507/8d9511ce/attachment.html>