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

[Douglas Gregor]

On Oct 28, 2009, at 1:39 PM, Chris Lattner <clattner at apple.com> wrote:

> On Oct 26, 2009, at 3:34 PM, Douglas Gregor wrote:
>>>
>>> void foo() {
>>> const int x[] = { 1, 2,3,4,5,6,7,8 };
>>> bar(x);
>>> }
>>
>> I believe that GCC is non-conforming in this regard, because  
>> recursive calls to "foo" would not have distinct "x" pointers. Note  
>> that this was fixed in GCC 4.3.4, so that they no longer promote  
>> the automatic variable to a constant if its address has been taken,  
>> as described in this bug report:
>>
>>    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38615
>>
>>> My understanding is that -fmerge-all-constants doesn't default to  
>>> being on.  I don't think this should be tied to it.
>>
>>
>> There are 3 levels of "merge-constants" in GCC:
>>
>> -fno-merge-constants: default at -O0, merges nothing
>> -fmerge-constants: default at -O, -O2, -O3, -Os. merges "x" in your  
>> example with GCC < 4.3.4, but shouldn't (according to the bug  
>> report) with GCC >= 4.3.4.
>> -fmerge-all-constants: must be explicitly-specified; merges "x" in  
>> your example (always), which is non-conforming behavior
>>
>> 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? We won't know the latter until it breaks something, but I'd  
be nervous about intentionally breaking code like this.

   -Doug