[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]

On Feb 18, 2009, at 6:16 PM, Dale Johannesen wrote:

>
> 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).

Another option that occurred to me: we could just setSection() on  
*all* STRING_CSTs.  Duncan, what do you think about that?

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