This is the mail archive of the gcc@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]

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.



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