[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

Chris Lattner clattner at apple.com
Wed Feb 18 17:52:11 PST 2009


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.

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


More information about the llvm-commits mailing list