This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: liveness analysis with stack slots


Maurizio Vitale writes:
 > 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.

Well, yes.  Those of us reading might be able to figure out for
ourselves what is happening!

I don't want the entire source, just a snippet that demonstrates the
problem.  Is it impossible to do that?

 > 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.

I'm guessing that gcc isn't running DCE after the simplification passe
that exposes the constant, but with no test case it's impossible to
say.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]