Andrew Haley <aph-gcc@xxxxxxxxxxxxxxxxxxx> 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.
>
