[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

[Dale Johannesen]

On Feb 18, 2009, at 5:52 PMPST, Chris Lattner wrote:

> On Feb 17, 2009, at 11:08 PM, Evan Cheng wrote:
>>>> 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 and I discussed this offline.  The result is that I agree that  
> there is nothing wrong with this patch, but that there is another  
> underlying bug that this is being used to hide.
>
> The problem is that darwin really needs the STRING_CST to be emitted  
> to a specific section.  The "right" answer is to change  
> darwin_build_constant_cfstring in config/darwin.c to tag the node as  
> needing to be in the cstring section, and then the codegen will do  
> the right thing.
>
> The problem is that DECL_SECTION cannot be used on STRING_CST.  Does  
> anyone know a good solution for this?  This is easy to fix in clang,  
> but it would be nice for llvm-gcc to not rely on subtle behavior of  
> the code generator for its correctness.

The most straightforward would be add a section_name field to the  
STRING_CST node (struct tree_string in tree.h).

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