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

[Douglas Gregor]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20091028/2519227b/attachment.html>