[LLVMdev] AsmPrinter behavior

[Nathan Jeffords]

On Fri, May 7, 2010 at 10:02 AM, Aaron Gray <aaronngray.lists at googlemail.com
> 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'.
>

I agree, I was going to put EmitASCII in, not sure about the zero fill,
though I use the zero fill fragment when handling common symbols.


>
> We also need to sort out COFF TLOF, and get rid of the directive stuff.
>

I think this Peter's patch takes care of this nicely.

-Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100507/510c839d/attachment.html>