[cfe-commits] Patch to change how const arrays/structs are handled

[Tanya Lattner]

Submitted new patch for review:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20091026/022930.html

-Tanya

On Oct 28, 2009, at 10:24 PM, Douglas Gregor wrote:

>
> On Oct 28, 2009, at 9:39 PM, Chris Lattner wrote:
>> On Oct 28, 2009, at 9:25 PM, Douglas Gregor wrote:
>>>>> So, we either need to tie this patch to -fmerge-all-constants  
>>>>> (where we allow such non-conforming behavior) or we need to keep  
>>>>> track of whether declarations have had their address taken (to  
>>>>> implement the equivalent of -fmerge-constants).
>>>>
>>>> Ok, I think it makes perfect sense to support this.  The question  
>>>> is whether we should default to doing this or not at various  
>>>> optimization levels.
>>>
>>> I'd like to have the behavior of GCC's -fmerge-constants at all  
>>> optimization levels. We could also support -fmerge-all-constants  
>>> as an explicit flag, but I don't think that's as important.
>>>
>>>> This optimization is a very nice win for common coding patterns,  
>>>> and the LLVM backend isn't "safe" in this respect anyway (it  
>>>> merges 'static' global constants with identical initializers).   
>>>> How much does it matter?
>>>
>>> How much does what matter? The optimization? Correctness of the  
>>> example?
>>
>> The correctness.  We know that a large amount of code builds with  
>> GCC 4.2 (and llvm-gcc for that matter) which do have this  
>> misfeature.  Code doesn't actually compare the addresses of  
>> different instances of variables from recursive calls and expect  
>> them to compare unequal in practice.
>
>
> Meh.
>
> /me places an "I told you so" in has back pocket for safe keeping.
>
> 	- Doug
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

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