This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: 3.0 vs 3.0.1 on oopack's Max
Hi,
Jan Hubicka wrote:
> :) OK, it looks the problem is in the setcc code that causes partial
> register stall.
> Otherwise the 3.1 code looks good to me and also perofrms quite happily
> on Athlon that is free of the issue.
But sadly on Intel processors we have got a neat performance regression on a
very popular benchmark...
I know well that such short tests are not representative of real code but,
nonetheless, from a "marketing" point of view...
> The problem is relativly old - you have QImode register as result of setcc.
> The AND following it gets combined to have (SUBREG:SI (QIreg)) argument.
> In most of cases GCC gets around this by avoiding 8bit computations at all,
> but setcc must be 8bit. Richard has recently changes way setcc is expanded,
> so it is optimized better. One of better optimizations is this one and
> sadly it is not very lucky...
Thanks for the analysis!
(At this point all of this is still quite obscure to me, unfortunately... but
for me it is a good occasion to learn more!)
By the way, I found only one change to setcc (ix86_expand_setcc) involving the
branch, that is:
http://gcc.gnu.org/ml/gcc-patches/2001-07/msg01627.html
Which was a follow up to:
http://gcc.gnu.org/ml/gcc-patches/2001-07/msg01552.html
> I am not quite sure how to avoid gcc from doing this optimization.
> I will take a look overnight.
Thanks!
Paolo.