r212092 - Enable test/CodeGen/indirect-goto.c in 64b for local arrays

[Gerolf Hoflehner]

It is a long story, but in short in the current source base the 32b mode should not have worked. My fix disables an unsafe optimization (inclining) for block labels. In 32b block labels are still internally represented although they can be removed. In 64b everything is fine. Until we have more insight into the 32b root cause it makes sense to keep testing 64b mode. 

Gerolf

Sent from my iPhone

> On Jun 30, 2014, at 10:40 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
>> On Mon, Jun 30, 2014 at 10:10 PM, Gerolf Hoflehner <ghoflehner at apple.com> wrote:
>> Author: ghoflehner
>> Date: Tue Jul  1 00:10:06 2014
>> New Revision: 212092
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=212092&view=rev
>> Log:
>> Enable test/CodeGen/indirect-goto.c in 64b for local arrays
>> 
>> In 32b mode the reference count for block addresses
>> is not zero. This prevents inlining and constant
>> folding and causes the test to fail. Changing
>> the triple allows runnning the test in 64b mode.
>> 
>> The array in foo2 is now local instead of static until
>> at lower optimization levels the interprocedural constant
>> propagator is invoked before the global optimizer.
>> 
>> Modified:
>>    cfe/trunk/test/CodeGen/indirect-goto.c
>> 
>> Modified: cfe/trunk/test/CodeGen/indirect-goto.c
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/indirect-goto.c?rev=212092&r1=212091&r2=212092&view=diff
>> ==============================================================================
>> --- cfe/trunk/test/CodeGen/indirect-goto.c (original)
>> +++ cfe/trunk/test/CodeGen/indirect-goto.c Tue Jul  1 00:10:06 2014
>> @@ -1,5 +1,4 @@
>> -// RUN: %clang_cc1 -triple i386-unknown-unknown -O3 -emit-llvm -o - %s
>> -// DISABLED: %clang_cc1 -triple i386-unknown-unknown -O3 -emit-llvm -o - %s | grep "ret i32 2520"
>> +// RUN: %clang_cc1 -triple x86_64-unknown-unknown -O3 -emit-llvm -o - %s | grep "ret i32 2520"
> 
> Did your LLVM change regress the 32 bit behavior, then? Is that
> justified? (I haven't followed the LLVM thread, but it'd be useful to
> explain why that's appropriate here)
> 
>> 
>> static int foo(unsigned i) {
>>   void *addrs[] = { &&L1, &&L2, &&L3, &&L4, &&L5 };
>> @@ -15,7 +14,7 @@ static int foo(unsigned i) {
>> }
>> 
>> static int foo2(unsigned i) {
>> -  static const void *addrs[] = { &&L1, &&L2, &&L3, &&L4, &&L5 };
>> +  const void *addrs[] = { &&L1, &&L2, &&L3, &&L4, &&L5 };
>>   int res = 1;
>> 
>>   goto *addrs[i];
>> 
>> 
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits