> On Wed, Dec 16, 2015 at 05:24:25PM +0100, Jan Hubicka wrote:
> > I am trying to understand Jakub's debug code and perhaps it can be
> > improved. But in
> > the case of optimized out unused parameters I think it is perfectly
> > resonable to
> > say that the variable was optimized out.
>
> As long as the values that would be passed to the unused parameters are
> constant or live in memory or registers that isn't clobbered by the call in
> the caller, we have the ability to express that in the debug info now, and
> we should.
int
main ()
{
int l = 0;
asm ("" : "=r" (l) : "0" (l));
a = foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
asm volatile ("" :: "r" (l));
return 0;
}
the unused parameters are not constant because of the asm block and we simply
do not
compute them if cloning happens. The following patch to the testcase
Index: testsuite/gcc.dg/guality/pr36728-1.c
===================================================================
--- testsuite/gcc.dg/guality/pr36728-1.c (revision 231022)
+++ testsuite/gcc.dg/guality/pr36728-1.c (working copy)
@@ -7,7 +7,7 @@
int a, b;
int __attribute__((noinline))
-foo (int arg1, int arg2, int arg3, int arg4, int arg5, int arg6, int arg7)
+foo (int arg1, int arg2, int arg3, int arg4, int arg5, int arg6, int arg7, int
cst)
{
char *x = __builtin_alloca (arg7);
int __attribute__ ((aligned(32))) y;
@@ -48,7 +48,7 @@ main ()
{
int l = 0;
asm ("" : "=r" (l) : "0" (l));
- a = foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
+ a = foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30, 7);
asm volatile ("" :: "r" (l));
return 0;
}
makes it fail on GCC 5 tree, too. The extra unused constant argument makes GCC 5
to clone foo and optimize out l, too.
Honza
>
> > As you can see, the testcase explicitely prevents ipa-cp constant
> > propagation by the
> > asm statement. We can just update the testcases to use the parameters and
> > test
> > the original issue again.
>
> No, the testcase intentionally wants to test unused arguments, they happen
> in quite a lot of code and "optimized out" is not really desirable answer if
> we can provide the values some other way.
>
> Jakub
