Re: liveness analysis with stack slots

[Maurizio Vitale <mav at cuma dot polymath-solutions dot lan>]

Andrew Haley <aph-gcc@littlepinkcloud.COM> writes:

> Maurizio Vitale writes:
>  > 
>> 
>  > Can somebody shed some light on this and hint at why GCC (and the
>  > Intel compiler) decide that they cannot remove that code?
>
> It would be easy for us to do so if you provided a test case.  Without
> one it's impossible.  It doesn't look to me like the expression is
> totally dead, but without the source I can't tell.

The entire source is large and I don't think it would help much other
than allowing people to run experiments on their own.
But I can post GCC dumps at intermediate steps for a short function if
that's helpful.

An example (different from the one in the previous post to make
clearer that the expression is dead) is the following:

    int main (int,char**) {
      sc_int<16> i16_3 = 3;
      sc_int<16> i16_2 = 2;
      sc_int<12>    i12;
      sc_int<32>    i32;
      sc_int_base   ib4_10 (4,10);
      sc_fixed<16,2> f16_2_4 = 4;
      sc_fixed<16,1> f16_1_5 = 5;

      MARK ("B assign");
      int xx = meta_eval (::left (_1), i12+i32, i16_3);
      MARK ("E assign");
      std::cout << xx;
    }

the complete assembly is:

.globl main
	.type	main, @function
main:
.LFB4206:
	subq	$504, %rsp
.LCFI21:
	movw	$3, 400(%rsp)
	movw	$3, 384(%rsp)
	movw	$3, 368(%rsp)
	movw	$3, 352(%rsp)
	movw	$3, 480(%rsp)
	movw	$2, 336(%rsp)
	movw	$2, 320(%rsp)
	movw	$2, 304(%rsp)
	movw	$2, 288(%rsp)
	movw	$2, 464(%rsp)
	movw	$0, 256(%rsp)
	movw	$0, 240(%rsp)
	movw	$0, 272(%rsp)
	movw	$0, 448(%rsp)
	movl	$0, 64(%rsp)
	movl	$0, 48(%rsp)
	movl	$0, 80(%rsp)
	movl	$0, 96(%rsp)
	movw	$4, 224(%rsp)
	movw	$4, 208(%rsp)
	movw	$4, 192(%rsp)
	movw	$4, 176(%rsp)
	movw	$4, 432(%rsp)
	movw	$5, 160(%rsp)
	movw	$5, 144(%rsp)
	movw	$5, 128(%rsp)
	movw	$5, 112(%rsp)
	movw	$5, 416(%rsp)
#APP
	#### B assign
#NO_APP
	leaq	96(%rsp), %rax
	movq	%rsp, (%rsp)
	movq	%rax, 40(%rsp)
	leaq	448(%rsp), %rax
	movq	%rax, 32(%rsp)
	leaq	32(%rsp), %rax
	movq	%rax, 8(%rsp)
	leaq	480(%rsp), %rax
	movq	%rax, 16(%rsp)
#APP
	#### E assign
#NO_APP
	movl	$33, %esi
	movl	$_ZSt4cout, %edi
	call	_ZNSolsEi
	xorl	%eax, %eax
	addq	$504, %rsp
	ret
.LFE4206:
	.size	main, .-main
	.section	.rodata.str1.1

Everything looks rather dead to me (including the construction of objects that are never used, but let's focus on
the part between ####....####.
Interestingly, if I remove the output of xx everything (I mean _everything_) is correctly removed and main becomes:

.globl main
	.type	main, @function
main:
.LFB4206:
#APP
	#### B assign
	#### E assign
#NO_APP
	xorl	%eax, %eax
	ret
.LFE4206:

So for some reason GCC believes that the fact that xx is alive makes
everything else alive (even if the value for xx is the constant $33
which is computed at compile time). What is even more surprising is
that using xx makes:
      sc_fixed<16,2> f16_2_4 = 4;
      sc_fixed<16,1> f16_1_5 = 5;
live even though they're mentioned nowhere.

So the question is why GCC keeps a dependence between xx and
everything else even though the value of xx doesn't depend on anything
and all the code is in plain sight before him.

Regards,

        Maurizio
>
>  > I remember a few years ago GCC had problems with liveness analysis w/
>  > stack slots. Is that still the case?
>
> I don't think so.
>
> Andrew.
>