r177819 - Make clang to mark static stack allocations with lifetime markers to enable a more aggressive stack coloring.

[Nadav Rotem]

Hi Ulrich, 

Thanks for looking at this failure.  Does the IR look correct ?  This test passes on other targets, so I suspect that the change perturbed the IR and exposed a bug in the PPC target. Does that sound right ?  One way to debug this would be to disable the machine-level pass that optimizes stack slots and to see if there is a problem there.  Please let me know if I can help. BTW, there is also a failure in the GDB build bot that I am now trying to figure out. 

Thanks,
Nadav

On Mar 25, 2013, at 11:10 AM, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote:

> 
> Nadav,
> 
> this commit causes a testsuite failure in
> SingleSource/UnitTests/Vector/sumarray-dbl on powerpc64-linux.   The test
> case is supposed to output:
> 488862 490096 491331 492566 493800 495035 496269 497504
> but after this commit it outputs instead:
> 497504 496269 495035 493800 492566 491331 490096 488862
> so the order of the output number is exactly reversed.
> 
> Looking at the differences in the generated .ll files, it seems that there
> is actually no change in computing the values, it's simply that when
> generating the printf call, the order of arguments is inverted:
> 
> for.end9:                                         ; preds = %for.body4
> -  %sumV.sroa.0.0.vec.extract = extractelement <8 x double> %add, i32 0
> -  %sumV.sroa.0.8.vec.extract = extractelement <8 x double> %add, i32 1
> -  %sumV.sroa.0.16.vec.extract = extractelement <8 x double> %add, i32 2
> -  %sumV.sroa.0.24.vec.extract = extractelement <8 x double> %add, i32 3
> -  %sumV.sroa.0.32.vec.extract = extractelement <8 x double> %add, i32 4
> -  %sumV.sroa.0.40.vec.extract = extractelement <8 x double> %add, i32 5
> -  %sumV.sroa.0.48.vec.extract = extractelement <8 x double> %add, i32 6
> -  %sumV.sroa.0.56.vec.extract = extractelement <8 x double> %add, i32 7
> -  %call.i = tail call signext i32 (i8*, ...)* @printf(i8* getelementptr
> inbounds ([25 x i8]* @.str, i64 0, i64 0), double
> %sumV.sroa.0.0.vec.extract, double %sumV.s
> roa.0.8.vec.extract, double %sumV.sroa.0.16.vec.extract, double
> %sumV.sroa.0.24.vec.extract, double %sumV.sroa.0.32.vec.extract, double
> %sumV.sroa.0.40.vec.extract,
> double %sumV.sroa.0.48.vec.extract, double %sumV.sroa.0.56.vec.extract) #1
> +  %bitcast = extractelement <8 x double> %add, i32 7
> +  %11 = extractelement <8 x double> %add, i32 6
> +  %12 = extractelement <8 x double> %add, i32 5
> +  %13 = extractelement <8 x double> %add, i32 4
> +  %14 = extractelement <8 x double> %add, i32 3
> +  %15 = extractelement <8 x double> %add, i32 2
> +  %16 = extractelement <8 x double> %add, i32 1
> +  %17 = extractelement <8 x double> %add, i32 0
> +  %call.i = call signext i32 (i8*, ...)* @printf(i8* getelementptr
> inbounds ([25 x i8]* @.str, i64 0, i64 0), double %bitcast, double %11,
> double %12, double %13, d
> ouble %14, double %15, double %16, double %17) #1
>   ret i32 0
> 
> Any thoughts what's going on here?
> 
> 
> Mit freundlichen Gruessen / Best Regards
> 
> Ulrich Weigand
> 
> --
>  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
>  STSM, GNU/Linux compilers and toolchain
>  IBM Deutschland Research & Development GmbH
>  Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
> Wittkopp
>  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
> Stuttgart, HRB 243294

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