[llvm-commits] [llvm] r64877 - in /llvm/trunk: lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp lib/Target/PowerPC/AsmPrinter/PPCAsmPrinter.cpp lib/Target/X86/AsmPrinter/X86ATTAsmPrinter.cpp test/CodeGen/X86/cstring.ll

[Evan Cheng]

On Feb 17, 2009, at 10:07 PM, Chris Lattner wrote:

> On Feb 17, 2009, at 9:55 PM, Evan Cheng wrote:
>>>>> Evan, this seems like the wrong fix.  What *requires* an empty  
>>>>> string
>>>>> to go into the cstring section?  If there is some semantics that
>>>>> require it, then whatever produces the llvm global should set the
>>>>> section of the global to the cstring section explicitly.
>>>>
>>>> I don't see why this is wrong/ Per revision 63142,target asm info  
>>>> has already decided this particular GV should go into cstring.  
>>>> But the asm printer then decided to put it in BSS (which means it  
>>>> cannot be coalesced) because the initializer is empty. This patch  
>>>> makes sure asm printer doesn't try to out smart itself.
>>>
>>> Why is this important?
>>
>> rdar://6479858. It's a minor size win, but more importantly it  
>> avoids linker warning. That means fewer complaints about llvm-gcc  
>> (and it has been reported at least twice so far at Apple).
>
> Then this is not an optimization, this is a semantic property.   
> Whatever is creating that literal string should pin it in the  
> section that it requires it to be in.

I don't understand your objection. What's wrong with putting constant  
array of i8 terminated with zero into cstring sections? Do we need to  
have the frontend pre-determine the sections for all of these strings?

Evan

>
> -Chris
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20090217/dc3d0d59/attachment.html>