Re: gcc-2.7 creates faster code than pgcc-1.1.1

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[H.J. Lu]

Hi,

It seems that "movzb? %al,%?ax" may be faster than "and? $255,%?ax".
This patch for egcs 1.1.2 seems to make gzip faster.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)
---
Thu Mar  4 14:04:49 1999  H.J. Lu  (hjl@gnu.org)

	* config/i386/i386.md (zero_extendqihi2): Use "and" when target
	and source are both "ax" only if TARGET_ZERO_EXTEND_WITH_AND is
	true.
	(zero_extendqisi2): Likewise.

--- ../../../import/egcs-1.1.x/egcs/gcc/config/i386/i386.md	Sun Feb 14 08:30:40 1999
+++ config/i386/i386.md	Thu Mar  4 13:46:07 1999
@@ -1738,7 +1741,7 @@
   {
   rtx xops[2];
 
-  if ((TARGET_ZERO_EXTEND_WITH_AND || REGNO (operands[0]) == 0)
+  if ((TARGET_ZERO_EXTEND_WITH_AND || (0 & REGNO (operands[0]) == 0))
       && REG_P (operands[1]) 
       && REGNO (operands[0]) == REGNO (operands[1]))
     {
@@ -1819,7 +1822,7 @@
   {
   rtx xops[2];
 
-  if ((TARGET_ZERO_EXTEND_WITH_AND || REGNO (operands[0]) == 0)
+  if ((TARGET_ZERO_EXTEND_WITH_AND || (0 & REGNO (operands[0]) == 0))
       && REG_P (operands[1]) 
       && REGNO (operands[0]) == REGNO (operands[1]))
     {

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Martin v. Loewis]

> -  if ((TARGET_ZERO_EXTEND_WITH_AND || REGNO (operands[0]) == 0)
> +  if ((TARGET_ZERO_EXTEND_WITH_AND || (0 & REGNO (operands[0]) == 0))

It's late, so I'm probably going to say stupid things, but ...

Isn't (0 & REGNO (operands[0]) == 0) always 0? Why isn't the condition
just deleted?

Curious,
Martin

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[H.J. Lu]

> 
> > -  if ((TARGET_ZERO_EXTEND_WITH_AND || REGNO (operands[0]) == 0)
> > +  if ((TARGET_ZERO_EXTEND_WITH_AND || (0 & REGNO (operands[0]) == 0))
> 
> It's late, so I'm probably going to say stupid things, but ...
> 
> Isn't (0 & REGNO (operands[0]) == 0) always 0? Why isn't the condition
> just deleted?
> 

It is easier to back it out if we decide it is not a good idea after
all.

-- 
H.J. Lu (hjl@gnu.org)

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Joe Buck]

> > Isn't (0 & REGNO (operands[0]) == 0) always 0? Why isn't the condition
> > just deleted?
> > 
> 
> It is easier to back it out if we decide it is not a good idea after
> all.

If so, isn't the usual gcc convention to do that
#if 0
#endif

?

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[H.J. Lu]

> 
> 
> > > Isn't (0 & REGNO (operands[0]) == 0) always 0? Why isn't the condition
> > > just deleted?
> > > 
> > 
> > It is easier to back it out if we decide it is not a good idea after
> > all.
> 
> If so, isn't the usual gcc convention to do that
> #if 0
> #endif
> 

I thought it was the convention for i386. At least, that is what
was done to TARGET_CMOVE/CC_FCOMI.

-- 
H.J. Lu (hjl@gnu.org)

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[H.J. Lu]

> 
> 
> > > Isn't (0 & REGNO (operands[0]) == 0) always 0? Why isn't the condition
> > > just deleted?
> > > 
> > 
> > It is easier to back it out if we decide it is not a good idea after
> > all.
> 
> If so, isn't the usual gcc convention to do that
> #if 0
> #endif
> 

I thought it was the convention for i386. At least, that is what
was done to TARGET_CMOVE/CC_FCOMI.

-- 
H.J. Lu (hjl@gnu.org)

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Joe Buck]

> > Isn't (0 & REGNO (operands[0]) == 0) always 0? Why isn't the condition
> > just deleted?
> > 
> 
> It is easier to back it out if we decide it is not a good idea after
> all.

If so, isn't the usual gcc convention to do that
#if 0
#endif

?

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[craig]

>It is easier to back it out if we decide it is not a good idea after
>all.

Just for my own sanity: we're not in any way seriously considering
this *performance* patch for 1.1.2, are we??!

It'd be great to see it, or something like it, in 1.2, of course.

        tq vm, (burley)

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jeffrey A Law]

  In message < 19990305145306.4796.qmail@deer >you write:
  > >It is easier to back it out if we decide it is not a good idea after
  > >all.
  > 
  > Just for my own sanity: we're not in any way seriously considering
  > this *performance* patch for 1.1.2, are we??!
Absolutely not.

Once we can get 1.1.2 finished I'll dig out my work to improve the zero
extension code and submit it.  It's far more complete than HJ's hack.

jeff

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jeffrey A Law]

  In message < 19990305145306.4796.qmail@deer >you write:
  > >It is easier to back it out if we decide it is not a good idea after
  > >all.
  > 
  > Just for my own sanity: we're not in any way seriously considering
  > this *performance* patch for 1.1.2, are we??!
Absolutely not.

Once we can get 1.1.2 finished I'll dig out my work to improve the zero
extension code and submit it.  It's far more complete than HJ's hack.

jeff

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[craig]

>It is easier to back it out if we decide it is not a good idea after
>all.

Just for my own sanity: we're not in any way seriously considering
this *performance* patch for 1.1.2, are we??!

It'd be great to see it, or something like it, in 1.2, of course.

        tq vm, (burley)

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[H.J. Lu]

> 
> > -  if ((TARGET_ZERO_EXTEND_WITH_AND || REGNO (operands[0]) == 0)
> > +  if ((TARGET_ZERO_EXTEND_WITH_AND || (0 & REGNO (operands[0]) == 0))
> 
> It's late, so I'm probably going to say stupid things, but ...
> 
> Isn't (0 & REGNO (operands[0]) == 0) always 0? Why isn't the condition
> just deleted?
> 

It is easier to back it out if we decide it is not a good idea after
all.

-- 
H.J. Lu (hjl@gnu.org)

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jeffrey A Law]

  In message < 199903050001.BAA00973@mira.isdn.cs.tu-berlin.de >you write:
  > > -  if ((TARGET_ZERO_EXTEND_WITH_AND || REGNO (operands[0]) == 0)
  > > +  if ((TARGET_ZERO_EXTEND_WITH_AND || (0 & REGNO (operands[0]) == 0))
  > 
  > It's late, so I'm probably going to say stupid things, but ...
  > 
  > Isn't (0 & REGNO (operands[0]) == 0) always 0? Why isn't the condition
  > just deleted?
Disabling the code like that is actually the wrong thing to do for certain
processor variants.

I need to dust off my changes to this code which do the right thing when
optimizing for size, PPro, Pent and older x86 variants.

It's not as simple as just deleting the test like that.

jeff

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[H.J. Lu]

> 
> 
>   In message < 199903050001.BAA00973@mira.isdn.cs.tu-berlin.de >you write:
>   > > -  if ((TARGET_ZERO_EXTEND_WITH_AND || REGNO (operands[0]) == 0)
>   > > +  if ((TARGET_ZERO_EXTEND_WITH_AND || (0 & REGNO (operands[0]) == 0))
>   > 
>   > It's late, so I'm probably going to say stupid things, but ...
>   > 
>   > Isn't (0 & REGNO (operands[0]) == 0) always 0? Why isn't the condition
>   > just deleted?
> Disabling the code like that is actually the wrong thing to do for certain
> processor variants.
> 
> I need to dust off my changes to this code which do the right thing when
> optimizing for size, PPro, Pent and older x86 variants.
> 
> It's not as simple as just deleting the test like that.
> 

Just keep in mind that this small change speeds up gzip by 10-20% on
PPro, P/II and maybe P/III. It may be true also for 386. According
to TARGET_ZERO_EXTEND_WITH_AND, only 486 and Pentium seems to prefer
"and".

BTW, FWIW, "movzbl" has 3 bytes and "addl" has 5 bytes. So "movzbl" is
smaller and faster on 386, PPro, P/II and P/III.


-- 
H.J. Lu (hjl@gnu.org)

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jeffrey A Law]

  In message < m10Ilq3-00000YC@ocean.lucon.org >you write:

  > Just keep in mind that this small change speeds up gzip by 10-20% on
  > PPro, P/II and maybe P/III. It may be true also for 386. According
  > to TARGET_ZERO_EXTEND_WITH_AND, only 486 and Pentium seems to prefer
  > "and".
But that does not make the patch correct.  Period.


  > BTW, FWIW, "movzbl" has 3 bytes and "addl" has 5 bytes. So "movzbl" is
  > smaller and faster on 386, PPro, P/II and P/III.
Correct.  That is precisely one of the changes in my patch.

jeff

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jeffrey A Law]

  In message < m10Ilq3-00000YC@ocean.lucon.org >you write:

  > Just keep in mind that this small change speeds up gzip by 10-20% on
  > PPro, P/II and maybe P/III. It may be true also for 386. According
  > to TARGET_ZERO_EXTEND_WITH_AND, only 486 and Pentium seems to prefer
  > "and".
But that does not make the patch correct.  Period.


  > BTW, FWIW, "movzbl" has 3 bytes and "addl" has 5 bytes. So "movzbl" is
  > smaller and faster on 386, PPro, P/II and P/III.
Correct.  That is precisely one of the changes in my patch.

jeff

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[H.J. Lu]

> 
> 
>   In message < 199903050001.BAA00973@mira.isdn.cs.tu-berlin.de >you write:
>   > > -  if ((TARGET_ZERO_EXTEND_WITH_AND || REGNO (operands[0]) == 0)
>   > > +  if ((TARGET_ZERO_EXTEND_WITH_AND || (0 & REGNO (operands[0]) == 0))
>   > 
>   > It's late, so I'm probably going to say stupid things, but ...
>   > 
>   > Isn't (0 & REGNO (operands[0]) == 0) always 0? Why isn't the condition
>   > just deleted?
> Disabling the code like that is actually the wrong thing to do for certain
> processor variants.
> 
> I need to dust off my changes to this code which do the right thing when
> optimizing for size, PPro, Pent and older x86 variants.
> 
> It's not as simple as just deleting the test like that.
> 

Just keep in mind that this small change speeds up gzip by 10-20% on
PPro, P/II and maybe P/III. It may be true also for 386. According
to TARGET_ZERO_EXTEND_WITH_AND, only 486 and Pentium seems to prefer
"and".

BTW, FWIW, "movzbl" has 3 bytes and "addl" has 5 bytes. So "movzbl" is
smaller and faster on 386, PPro, P/II and P/III.


-- 
H.J. Lu (hjl@gnu.org)

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jeffrey A Law]

  In message < 199903050001.BAA00973@mira.isdn.cs.tu-berlin.de >you write:
  > > -  if ((TARGET_ZERO_EXTEND_WITH_AND || REGNO (operands[0]) == 0)
  > > +  if ((TARGET_ZERO_EXTEND_WITH_AND || (0 & REGNO (operands[0]) == 0))
  > 
  > It's late, so I'm probably going to say stupid things, but ...
  > 
  > Isn't (0 & REGNO (operands[0]) == 0) always 0? Why isn't the condition
  > just deleted?
Disabling the code like that is actually the wrong thing to do for certain
processor variants.

I need to dust off my changes to this code which do the right thing when
optimizing for size, PPro, Pent and older x86 variants.

It's not as simple as just deleting the test like that.

jeff

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Martin v. Loewis]

> -  if ((TARGET_ZERO_EXTEND_WITH_AND || REGNO (operands[0]) == 0)
> +  if ((TARGET_ZERO_EXTEND_WITH_AND || (0 & REGNO (operands[0]) == 0))

It's late, so I'm probably going to say stupid things, but ...

Isn't (0 & REGNO (operands[0]) == 0) always 0? Why isn't the condition
just deleted?

Curious,
Martin

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[H.J. Lu]

Hi,

It seems that "movzb? %al,%?ax" may be faster than "and? $255,%?ax".
This patch for egcs 1.1.2 seems to make gzip faster.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)
---
Thu Mar  4 14:04:49 1999  H.J. Lu  (hjl@gnu.org)

	* config/i386/i386.md (zero_extendqihi2): Use "and" when target
	and source are both "ax" only if TARGET_ZERO_EXTEND_WITH_AND is
	true.
	(zero_extendqisi2): Likewise.

--- ../../../import/egcs-1.1.x/egcs/gcc/config/i386/i386.md	Sun Feb 14 08:30:40 1999
+++ config/i386/i386.md	Thu Mar  4 13:46:07 1999
@@ -1738,7 +1741,7 @@
   {
   rtx xops[2];
 
-  if ((TARGET_ZERO_EXTEND_WITH_AND || REGNO (operands[0]) == 0)
+  if ((TARGET_ZERO_EXTEND_WITH_AND || (0 & REGNO (operands[0]) == 0))
       && REG_P (operands[1]) 
       && REGNO (operands[0]) == REGNO (operands[1]))
     {
@@ -1819,7 +1822,7 @@
   {
   rtx xops[2];
 
-  if ((TARGET_ZERO_EXTEND_WITH_AND || REGNO (operands[0]) == 0)
+  if ((TARGET_ZERO_EXTEND_WITH_AND || (0 & REGNO (operands[0]) == 0))
       && REG_P (operands[1]) 
       && REGNO (operands[0]) == REGNO (operands[1]))
     {

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Òåðåõèí Âÿ÷åñëàâ]

>On Fri, Mar 05, 1999 at 12:23:46PM -0500, Alfred Perlstein wrote:
>> > I any way "movzb? %al,%?ax" and "and? $255,%?ax" takes 1 tick both.
>> > So this is a kind of mistery with this instructions.
>>
>> I think the magic lies in that with register renaming, instruction
>> caches and all the 'behind the scenes' optimizations PPro and later
>> versions of x86 chips can do.  It really should be investigated more.
>
>It has nothing to do with register renaming.
>
>It is most likely to be related to instruction alignment -- some
>important insn in the loop is straddling a 16-byte boundary, which
>requires an extra cycle to decode.
>
>I've seen such create up to a 20% difference in runtime on a small loop.
>


It has nothing to deal with para boundary. In movz case xorb insn crosses
para boundary
while with andl no insn crosses para boundary.

Sincerely Yours, Eugene.

P.S. For H.J.Lu -- I do not state that things go slower with movz. Slow down
I get were 1% (this can be statistical error). Nevertheless there is no
speed up in
most cases too (or such a huge speed up as with decompression).
We should try to find out more why and how this happens.
BTW I have PPro 180MHz.

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Òåðåõèí Âÿ÷åñëàâ]

>On Fri, Mar 05, 1999 at 12:23:46PM -0500, Alfred Perlstein wrote:
>> > I any way "movzb? %al,%?ax" and "and? $255,%?ax" takes 1 tick both.
>> > So this is a kind of mistery with this instructions.
>>
>> I think the magic lies in that with register renaming, instruction
>> caches and all the 'behind the scenes' optimizations PPro and later
>> versions of x86 chips can do.  It really should be investigated more.
>
>It has nothing to do with register renaming.
>
>It is most likely to be related to instruction alignment -- some
>important insn in the loop is straddling a 16-byte boundary, which
>requires an extra cycle to decode.
>
>I've seen such create up to a 20% difference in runtime on a small loop.
>


It has nothing to deal with para boundary. In movz case xorb insn crosses
para boundary
while with andl no insn crosses para boundary.

Sincerely Yours, Eugene.

P.S. For H.J.Lu -- I do not state that things go slower with movz. Slow down
I get were 1% (this can be statistical error). Nevertheless there is no
speed up in
most cases too (or such a huge speed up as with decompression).
We should try to find out more why and how this happens.
BTW I have PPro 180MHz.

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Терехин Вячеслав]

>Hi,
>
>It seems that "movzb? %al,%?ax" may be faster than "and? $255,%?ax".
>This patch for egcs 1.1.2 seems to make gzip faster.
>
>Thanks.
>
>


Yes it maybe, but not allways, this is not the case as you can see from my
message:
Decompression becomes faster, while compression becomes slower.

More over this generally slow down code. I do have my own patch to egcs
doing
the same thing as yours. To turn on suppressing of andl in favor of movz of
use -mextendz-with-movz.
Compiling of several programms shows general slow down.

I any way "movzb? %al,%?ax" and "and? $255,%?ax" takes 1 tick both.
So this is a kind of mistery with this instructions.

As you can see from my message this change in uncompression code
yields 20% performance boost. At the same time all the loop dealing with crc
is
0x15 bytes long and takes 50% of time. The one instruction from it 5 or 3
bytes long
saves 20% total time or 40% of loop time. This can not be at all. But it is.

Sincerely Yours, Eugene.

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Alfred Perlstein]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

On Fri, 5 Mar 1999, [koi8-r] ôÅÒÅÈÉÎ ÷ÑÞÅÓÌÁ× wrote:

> >Hi,
> >
> >It seems that "movzb? %al,%?ax" may be faster than "and? $255,%?ax".
> >This patch for egcs 1.1.2 seems to make gzip faster.
> >
> >Thanks.
> >
> >
> 
> 
> Yes it maybe, but not allways, this is not the case as you can see from my
> message:
> Decompression becomes faster, while compression becomes slower.
> 
> More over this generally slow down code. I do have my own patch to egcs
> doing
> the same thing as yours. To turn on suppressing of andl in favor of movz of
> use -mextendz-with-movz.
> Compiling of several programms shows general slow down.
> 
> I any way "movzb? %al,%?ax" and "and? $255,%?ax" takes 1 tick both.
> So this is a kind of mistery with this instructions.

I think the magic lies in that with register renaming, instruction
caches and all the 'behind the scenes' optimizations PPro and later
versions of x86 chips can do.  It really should be investigated more.

Stalling any one of thses features can kill performance, any ideas
on what's feature could be hit by this in gzip, but at the same time
cause bad bahavior in other applications?

-Alfred

> 
> As you can see from my message this change in uncompression code
> yields 20% performance boost. At the same time all the loop dealing with crc
> is
> 0x15 bytes long and takes 50% of time. The one instruction from it 5 or 3
> bytes long
> saves 20% total time or 40% of loop time. This can not be at all. But it is.
> 
> Sincerely Yours, Eugene.
> 

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Richard Henderson]

On Fri, Mar 05, 1999 at 12:23:46PM -0500, Alfred Perlstein wrote:
> > I any way "movzb? %al,%?ax" and "and? $255,%?ax" takes 1 tick both.
> > So this is a kind of mistery with this instructions.
> 
> I think the magic lies in that with register renaming, instruction
> caches and all the 'behind the scenes' optimizations PPro and later
> versions of x86 chips can do.  It really should be investigated more.

It has nothing to do with register renaming. 

It is most likely to be related to instruction alignment -- some
important insn in the loop is straddling a 16-byte boundary, which
requires an extra cycle to decode.

I've seen such create up to a 20% difference in runtime on a small loop.


r~

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Richard Henderson]

On Fri, Mar 05, 1999 at 12:23:46PM -0500, Alfred Perlstein wrote:
> > I any way "movzb? %al,%?ax" and "and? $255,%?ax" takes 1 tick both.
> > So this is a kind of mistery with this instructions.
> 
> I think the magic lies in that with register renaming, instruction
> caches and all the 'behind the scenes' optimizations PPro and later
> versions of x86 chips can do.  It really should be investigated more.

It has nothing to do with register renaming. 

It is most likely to be related to instruction alignment -- some
important insn in the loop is straddling a 16-byte boundary, which
requires an extra cycle to decode.

I've seen such create up to a 20% difference in runtime on a small loop.


r~

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Alfred Perlstein]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

On Fri, 5 Mar 1999, [koi8-r] ôÅÒÅÈÉÎ ÷ÑÞÅÓÌÁ× wrote:

> >Hi,
> >
> >It seems that "movzb? %al,%?ax" may be faster than "and? $255,%?ax".
> >This patch for egcs 1.1.2 seems to make gzip faster.
> >
> >Thanks.
> >
> >
> 
> 
> Yes it maybe, but not allways, this is not the case as you can see from my
> message:
> Decompression becomes faster, while compression becomes slower.
> 
> More over this generally slow down code. I do have my own patch to egcs
> doing
> the same thing as yours. To turn on suppressing of andl in favor of movz of
> use -mextendz-with-movz.
> Compiling of several programms shows general slow down.
> 
> I any way "movzb? %al,%?ax" and "and? $255,%?ax" takes 1 tick both.
> So this is a kind of mistery with this instructions.

I think the magic lies in that with register renaming, instruction
caches and all the 'behind the scenes' optimizations PPro and later
versions of x86 chips can do.  It really should be investigated more.

Stalling any one of thses features can kill performance, any ideas
on what's feature could be hit by this in gzip, but at the same time
cause bad bahavior in other applications?

-Alfred

> 
> As you can see from my message this change in uncompression code
> yields 20% performance boost. At the same time all the loop dealing with crc
> is
> 0x15 bytes long and takes 50% of time. The one instruction from it 5 or 3
> bytes long
> saves 20% total time or 40% of loop time. This can not be at all. But it is.
> 
> Sincerely Yours, Eugene.
> 

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[H.J. Lu]

> 
> 
> Yes it maybe, but not allways, this is not the case as you can see from my
> message:
> Decompression becomes faster, while compression becomes slower.
> 

That is not the case for me. With my patch, I got:

# time ./gzip.new    -cd egcs-1.1.1.tar.gz  >! /dev/null
./gzip.new -cd egcs-1.1.1.tar.gz >| /dev/null  2.71s user 0.05s system 99% cpu 2.778 total
# time ./gzip.new    -cd egcs-1.1.1.tar.gz  >! /dev/null
./gzip.new -cd egcs-1.1.1.tar.gz >| /dev/null  2.73s user 0.04s system 99% cpu 2.776 total
# time ./gzip.new    -cd egcs-1.1.1.tar.gz  >! /dev/null
./gzip.new -c egcs-1.1.1.tar.gz >| /dev/null  5.15s user 0.08s system 101% cpu 5.167 total
# time ./gzip.new    -c egcs-1.1.1.tar.gz  >! /dev/null
./gzip.new -c egcs-1.1.1.tar.gz >| /dev/null  5.14s user 0.06s system 99% cpu 5.211 total
# time ./gzip.new    -c egcs-1.1.1.tar.gz  >! /dev/null
./gzip.new -c egcs-1.1.1.tar.gz >| /dev/null  5.11s user 0.08s system 100% cpu 5.179 total

Without my patch, I got

# time ./gzip.1.1.2     -cd egcs-1.1.1.tar.gz  >! /dev/null
./gzip.1.1.2 -cd egcs-1.1.1.tar.gz >| /dev/null  3.34s user 0.03s system 100% cpu 3.367 total
# time ./gzip.1.1.2     -cd egcs-1.1.1.tar.gz  >! /dev/null
./gzip.1.1.2 -cd egcs-1.1.1.tar.gz >| /dev/null  3.36s user 0.03s system 99% cpu 3.406 total
# time ./gzip.1.1.2     -cd egcs-1.1.1.tar.gz  >! /dev/null
./gzip.1.1.2 -cd egcs-1.1.1.tar.gz >| /dev/null  3.32s user 0.08s system 100% cpu 3.399 total
# time ./gzip.1.1.2     -c egcs-1.1.1.tar.gz  >! /dev/null 
./gzip.1.1.2 -c egcs-1.1.1.tar.gz >| /dev/null  5.29s user 0.04s system 102% cpu 5.214 total
# time ./gzip.1.1.2     -c egcs-1.1.1.tar.gz  >! /dev/null 
./gzip.1.1.2 -c egcs-1.1.1.tar.gz >| /dev/null  5.30s user 0.03s system 100% cpu 5.327 total
# time ./gzip.1.1.2     -c egcs-1.1.1.tar.gz  >! /dev/null 
./gzip.1.1.2 -c egcs-1.1.1.tar.gz >| /dev/null  5.29s user 0.06s system 100% cpu 5.328 total

As you can see, my patch makes both decompression and compression
faster. BTW, it is done under dual Xeon 450Mhz.


H.J.

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[H.J. Lu]

> 
> 
> Yes it maybe, but not allways, this is not the case as you can see from my
> message:
> Decompression becomes faster, while compression becomes slower.
> 

That is not the case for me. With my patch, I got:

# time ./gzip.new    -cd egcs-1.1.1.tar.gz  >! /dev/null
./gzip.new -cd egcs-1.1.1.tar.gz >| /dev/null  2.71s user 0.05s system 99% cpu 2.778 total
# time ./gzip.new    -cd egcs-1.1.1.tar.gz  >! /dev/null
./gzip.new -cd egcs-1.1.1.tar.gz >| /dev/null  2.73s user 0.04s system 99% cpu 2.776 total
# time ./gzip.new    -cd egcs-1.1.1.tar.gz  >! /dev/null
./gzip.new -c egcs-1.1.1.tar.gz >| /dev/null  5.15s user 0.08s system 101% cpu 5.167 total
# time ./gzip.new    -c egcs-1.1.1.tar.gz  >! /dev/null
./gzip.new -c egcs-1.1.1.tar.gz >| /dev/null  5.14s user 0.06s system 99% cpu 5.211 total
# time ./gzip.new    -c egcs-1.1.1.tar.gz  >! /dev/null
./gzip.new -c egcs-1.1.1.tar.gz >| /dev/null  5.11s user 0.08s system 100% cpu 5.179 total

Without my patch, I got

# time ./gzip.1.1.2     -cd egcs-1.1.1.tar.gz  >! /dev/null
./gzip.1.1.2 -cd egcs-1.1.1.tar.gz >| /dev/null  3.34s user 0.03s system 100% cpu 3.367 total
# time ./gzip.1.1.2     -cd egcs-1.1.1.tar.gz  >! /dev/null
./gzip.1.1.2 -cd egcs-1.1.1.tar.gz >| /dev/null  3.36s user 0.03s system 99% cpu 3.406 total
# time ./gzip.1.1.2     -cd egcs-1.1.1.tar.gz  >! /dev/null
./gzip.1.1.2 -cd egcs-1.1.1.tar.gz >| /dev/null  3.32s user 0.08s system 100% cpu 3.399 total
# time ./gzip.1.1.2     -c egcs-1.1.1.tar.gz  >! /dev/null 
./gzip.1.1.2 -c egcs-1.1.1.tar.gz >| /dev/null  5.29s user 0.04s system 102% cpu 5.214 total
# time ./gzip.1.1.2     -c egcs-1.1.1.tar.gz  >! /dev/null 
./gzip.1.1.2 -c egcs-1.1.1.tar.gz >| /dev/null  5.30s user 0.03s system 100% cpu 5.327 total
# time ./gzip.1.1.2     -c egcs-1.1.1.tar.gz  >! /dev/null 
./gzip.1.1.2 -c egcs-1.1.1.tar.gz >| /dev/null  5.29s user 0.06s system 100% cpu 5.328 total

As you can see, my patch makes both decompression and compression
faster. BTW, it is done under dual Xeon 450Mhz.


H.J.

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Терехин Вячеслав]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

>Hi,
>
>It seems that "movzb? %al,%?ax" may be faster than "and? $255,%?ax".
>This patch for egcs 1.1.2 seems to make gzip faster.
>
>Thanks.
>
>


Yes it maybe, but not allways, this is not the case as you can see from my
message:
Decompression becomes faster, while compression becomes slower.

More over this generally slow down code. I do have my own patch to egcs
doing
the same thing as yours. To turn on suppressing of andl in favor of movz of
use -mextendz-with-movz.
Compiling of several programms shows general slow down.

I any way "movzb? %al,%?ax" and "and? $255,%?ax" takes 1 tick both.
So this is a kind of mistery with this instructions.

As you can see from my message this change in uncompression code
yields 20% performance boost. At the same time all the loop dealing with crc
is
0x15 bytes long and takes 50% of time. The one instruction from it 5 or 3
bytes long
saves 20% total time or 40% of loop time. This can not be at all. But it is.

Sincerely Yours, Eugene.

[-- Attachment #2: egcs.patch --]
[-- Type: text/x-diff, Size: 4005 bytes --]

--- egcs-1.1.1/gcc/config/i386/i386.h.orig	Thu Mar  4 10:59:56 1999
+++ egcs-1.1.1/gcc/config/i386/i386.h	Thu Mar  4 13:23:32 1999
@@ -80,7 +80,7 @@
 /* Masks for the -m switches */
 #define MASK_80387		000000000001	/* Hardware floating point */
 #define MASK_NOTUSED1		000000000002	/* bit not currently used */
-#define MASK_NOTUSED2		000000000004	/* bit not currently used */
+#define MASK_EXTENDZ_MOVZ	000000000004	/* Do not generate andl $255, %eax instead of movzbl %al, %eax */
 #define MASK_RTD		000000000010	/* Use ret that pops args */
 #define MASK_ALIGN_DOUBLE	000000000020	/* align doubles to 2 word boundary */
 #define MASK_SVR3_SHLIB		000000000040	/* Uninit locals into bss */
@@ -157,8 +157,9 @@
 #define TARGET_PENTIUMPRO (ix86_cpu == PROCESSOR_PENTIUMPRO)
 #define TARGET_USE_LEAVE (ix86_cpu == PROCESSOR_I386)
 #define TARGET_PUSH_MEMORY (ix86_cpu == PROCESSOR_I386)
-#define TARGET_ZERO_EXTEND_WITH_AND (ix86_cpu != PROCESSOR_I386 \
-				     && ix86_cpu != PROCESSOR_PENTIUMPRO)
+#define TARGET_EXTENDZ_MOVZ	((target_flags & MASK_EXTENDZ_MOVZ) != 0)	/* Generate andl $255, %eax instead of movzbl %al, %eax */
+#define TARGET_ZERO_EXTEND_WITH_AND (!TARGET_EXTENDZ_MOVZ || (ix86_cpu != PROCESSOR_I386 \
+				     && ix86_cpu != PROCESSOR_PENTIUMPRO))
 #define TARGET_DOUBLE_WITH_ADD (ix86_cpu != PROCESSOR_I386)
 #define TARGET_USE_BIT_TEST (ix86_cpu == PROCESSOR_I386)
 #define TARGET_UNROLL_STRLEN (ix86_cpu != PROCESSOR_I386)
@@ -207,6 +208,8 @@
   { "no-debug-arg",		-MASK_DEBUG_ARG },			\
   { "stack-arg-probe",		 MASK_STACK_PROBE },			\
   { "no-stack-arg-probe",	-MASK_STACK_PROBE },			\
+  { "extendz-with-movz",       	 MASK_EXTENDZ_MOVZ },			\
+  { "no-extendz-with-movz",     -MASK_EXTENDZ_MOVZ },			\
   { "windows",			0 },					\
   { "dll",			0 },					\
   SUBTARGET_SWITCHES							\
--- egcs-1.1.1/gcc/config/i386/i386.md.orig	Thu Mar  4 11:00:01 1999
+++ egcs-1.1.1/gcc/config/i386/i386.md	Thu Mar  4 13:09:21 1999
@@ -1674,7 +1674,7 @@
   {
   rtx xops[2];
 
-  if ((TARGET_ZERO_EXTEND_WITH_AND || REGNO (operands[0]) == 0) 
+  if (!TARGET_EXTENDZ_MOVZ && (TARGET_ZERO_EXTEND_WITH_AND || REGNO (operands[0]) == 0)
       && REG_P (operands[1]) && REGNO (operands[0]) == REGNO (operands[1]))
     {
       xops[0] = operands[0];
@@ -1738,7 +1738,7 @@
   {
   rtx xops[2];
 
-  if ((TARGET_ZERO_EXTEND_WITH_AND || REGNO (operands[0]) == 0)
+  if (!TARGET_EXTENDZ_MOVZ && (TARGET_ZERO_EXTEND_WITH_AND || REGNO (operands[0]) == 0)
       && REG_P (operands[1]) 
       && REGNO (operands[0]) == REGNO (operands[1]))
     {
@@ -1819,7 +1819,7 @@
   {
   rtx xops[2];
 
-  if ((TARGET_ZERO_EXTEND_WITH_AND || REGNO (operands[0]) == 0)
+  if (!TARGET_EXTENDZ_MOVZ && (TARGET_ZERO_EXTEND_WITH_AND || REGNO (operands[0]) == 0)
       && REG_P (operands[1]) 
       && REGNO (operands[0]) == REGNO (operands[1]))
     {
@@ -3553,13 +3553,13 @@
   switch (GET_CODE (operands[2]))
     {
     case CONST_INT:
-      if (GET_CODE (operands[0]) == MEM && MEM_VOLATILE_P (operands[0]))
+    if (GET_CODE (operands[0]) == MEM && MEM_VOLATILE_P (operands[0]))
 	break;
       intval = INTVAL (operands[2]);
       /* zero-extend 16->32? */
       if (intval == 0xffff && REG_P (operands[0])
 	  && (! REG_P (operands[1])
-	      || REGNO (operands[0]) != 0 || REGNO (operands[1]) != 0)
+	      || TARGET_EXTENDZ_MOVZ || REGNO (operands[0]) != 0 || REGNO (operands[1]) != 0)
 	  && (!TARGET_ZERO_EXTEND_WITH_AND || ! rtx_equal_p (operands[0], operands[1])))
 	{
 	  /* ??? tege: Should forget CC_STATUS only if we clobber a
@@ -3576,7 +3576,7 @@
       if (intval == 0xff && REG_P (operands[0])
 	  && !(REG_P (operands[1]) && NON_QI_REG_P (operands[1]))
 	  && (! REG_P (operands[1])
-	      || REGNO (operands[0]) != 0 || REGNO (operands[1]) != 0)
+	      || TARGET_EXTENDZ_MOVZ || REGNO (operands[0]) != 0 || REGNO (operands[1]) != 0)
 	  && (!TARGET_ZERO_EXTEND_WITH_AND || ! rtx_equal_p (operands[0], operands[1])))
 	{
 	  /* ??? tege: Should forget CC_STATUS only if we clobber a

gcc-2.7 creates faster code than pgcc-1.1.1

[Терехин Вячеслав]

As I wrote previously gcc-2.7.2.3 generates faster gzip
than egcs-1.1.1/pgcc-1.1.1 on PentiumPro.
The slowdown is greater than 10% on decompression operation.
This can be easily checked if you have RedHat 5.2.
The shipped gzip is gcc-2.7.2.3 compiled.

After several day of search I finally find out offending
instruction that slow down gzip compiled with egcs-1.1.1/pgcc-1.1.1
on PentiumPro 180MHz (132MB RAM) but the result seems crazy to me.

This instruction is:
andl $255, %eax
in flush_window (util.c) function body (it is inlined from updcrc)

if you manually replace it with
movzbl %al, $eax
this will boost decompression by 20%.

All the below staff is made in gzip-1.2.4a source folder.

$ make CFLAGS="-O6 -mpentiumpro"
$ time ./gzip -cd egcs-1.1.1.tar.gz > /dev/null

real    0m8.047s
user    0m7.970s
sys     0m0.070s

$time ./gzip -c egcs-1.1.1.tar.gz > /dev/null

real    0m12.646s
user    0m12.470s
sys     0m0.160s

$
gcc -c -DASMV -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DDIRENT=1 -O6 -mpentiumpro
util.c -S
$ sed 's/andl $255,%eax/movzbl %al, %eax/g' util.s > util.S
$
gcc -c -DASMV -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DDIRENT=1 -O6 -mpentiumpro
util.S
$ make CFLAGS="-O6 -mpentiumpro"

$ time ./gzip -cd egcs-1.1.1.tar.gz > /dev/null

real    0m6.658s
user    0m6.540s
sys     0m0.110s

$ time ./gzip -c egcs-1.1.1.tar.gz > /dev/null

real    0m12.688s
user    0m12.490s
sys     0m0.180s

All this staff do not apply to Pentium processor as far as I know
(I test it Pentium MMX 200MHz)

I do not know why this happens.
Anybody who knows how to deal with it, please, reply me
as soon as possible.

And finally if you have Pentium Pro or Pentium II please
do this check and report result to me.
I wonder whether I have brain damaged Pentium Pro.

Sincerely Yours, Eugene.


PS I am not on this mailing list.
Also it will be better if you will sent reply to bom@classic.iki.rssi.ru
I can not use it directly as mail can not be delivered by it to this list.

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jamie Lokier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

ôÅÒÅÈÉÎ ÷ÑÞÅÓÌÁ× wrote:
> After several day of search I finally find out offending
> instruction that slow down gzip compiled with egcs-1.1.1/pgcc-1.1.1
> on PentiumPro 180MHz (132MB RAM) but the result seems crazy to me.
> 
> This instruction is:
> andl $255, %eax
> in flush_window (util.c) function body (it is inlined from updcrc)
> 
> if you manually replace it with
> movzbl %al, $eax
> this will boost decompression by 20%.

In the past I have written hand-optimised assembly language, tuned for
the different x86 families, and I found movzbl to be a very effective
instruction on the Pentium Pro.  So what you describe sounds correct.

Another is to do xorl %eax,%eax just before loading something into %al.
That is fast on the PPro too.

-- Jamie

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Zack Weinberg]

On Thu, 4 Mar 1999 22:20:18 +0100, Jamie Lokier wrote:
>> After several day of search I finally find out offending
>> instruction that slow down gzip compiled with egcs-1.1.1/pgcc-1.1.1
>> on PentiumPro 180MHz (132MB RAM) but the result seems crazy to me.
>> 
>> This instruction is:
>> andl $255, %eax
>> in flush_window (util.c) function body (it is inlined from updcrc)
>> 
>> if you manually replace it with
>> movzbl %al, $eax
>> this will boost decompression by 20%.
>
>In the past I have written hand-optimised assembly language, tuned for
>the different x86 families, and I found movzbl to be a very effective
>instruction on the Pentium Pro.  So what you describe sounds correct.
>
>Another is to do xorl %eax,%eax just before loading something into %al.
>That is fast on the PPro too.

A related issue:  I see us generate a lot of code like this for loops over
strings:

loop:
	xorl %eax, %eax
	movb (%esi), %al
	incl %esi
	movb %al, (%edi)
	incl %edi
	testl %eax
	jne loop

After the first iteration, the xorl is unnecessary.  We ought to be able to
hoist it out of the loop.

zw

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jeffrey A Law]

  In message < 199903050104.UAA15335@octiron.phys.columbia.edu >you write:
  > A related issue:  I see us generate a lot of code like this for loops over
  > strings:
  > 
  > loop:
  > 	xorl %eax, %eax
  > 	movb (%esi), %al
  > 	incl %esi
  > 	movb %al, (%edi)
  > 	incl %edi
  > 	testl %eax
  > 	jne loop
  > 
  > After the first iteration, the xorl is unnecessary.  We ought to be able to
  > hoist it out of the loop.
True, but I don't believe the loop optimizer is prepared to do that since it
doesn't keep track of what bits are active vs what bits are inactive in a 
value.

jeff

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> True, but I don't believe the loop optimizer is prepared to do that since it
Jeff> doesn't keep track of what bits are active vs what bits are inactive in a 
Jeff> value.

	GCC is missing a general feature of value propagation which would
help with a lot of optimizations like this.  Hopefully this infrastructure
will be added or contributed someday.

David

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jeffrey A Law]

  In message < 9903050403.AA36338@marc.watson.ibm.com >you write:
  > 	GCC is missing a general feature of value propagation which would
  > help with a lot of optimizations like this.  Hopefully this infrastructure
  > will be added or contributed someday.
Most of the papers I've read have indicated only trivial gains from value
range propagation.  I've also had discussions with folks that have implemented
this opt in a commercial compiler -- it's so minor of a win that they didn't
consider it worth the effort.

It's best use appears to be for optimizing array bounds checking in languages
that require such checks.


jeff

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[craig]

>Most of the papers I've read have indicated only trivial gains from value
>range propagation.  I've also had discussions with folks that have implemented
>this opt in a commercial compiler -- it's so minor of a win that they didn't
>consider it worth the effort.

If that we really true *generally*, i.e. for floating-point as well,
then we could happily make -mieee the default for egcs/gcc on Alphas,
for example.  (This would make Alpha-generated floating-point code
much slower, of course, which is why I mention it: if it was possible
to use value-range propagation to determine when the special code-
generation normally needed for full IEEE range wasn't needed after all,
then some of that performance could be regained.)

But, I have to admit I can't document any really clear performance
wins from my own hand-tuned assembly code (written over the past few
decades) deriving solely from value-range propagation, especially
for *integer* (versus floating-point) values.

Generally, I think being able to avoid even checking for exceptional
values might be one source of performance wins from this: e.g. if
we knew it was "impossible" to divide by zero here, square-root a
negative number there, and so on, we could save generated extra
code, thus making Icache misses theoretically less frequent.

        tq vm, (burley)

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jeffrey A Law]

  In message < 19990305143358.4747.qmail@deer >you write:
  > If that we really true *generally*, i.e. for floating-point as well,
  > then we could happily make -mieee the default for egcs/gcc on Alphas,
  > for example.  (This would make Alpha-generated floating-point code
  > much slower, of course, which is why I mention it: if it was possible
  > to use value-range propagation to determine when the special code-
  > generation normally needed for full IEEE range wasn't needed after all,
  > then some of that performance could be regained.)
None of the papers discussed it in a floating point context, merely from an
integer context.  The basics were you had a range [min,max] and a bit which
indicated that the value was in or out of the range which was built up on a
basic block level for each expression.

The ranges were then propagated through the flow graph like any other local 
local property.  A trivial example, at a flow merge point where we had
one path with a range 0..4 inclusive and a range 6...12 inclusive the
resulting range would be 0..12 inclusive. [ It didn't try to track the hole
at 5. ]


As you mention it could be used to detect and eliminate things like domain
checks which depend solely on the range, not the precision.

Knowing that certain numbers can't be a NaN or Inf would lead to being able
to apply more identity operations on floating point values.

It'd be a lot of work though.  I suspect there's other lower hanging fruit
we can/should go after (assignment motion, partial dead code elimination,
sparse conditional constant propagation, etc).


jeff

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Joe Buck]

> None of the papers discussed it in a floating point context, merely from an
> integer context.  The basics were you had a range [min,max] and a bit which
> indicated that the value was in or out of the range which was built up on a
> basic block level for each expression.
> ...
> As you mention it could be used to detect and eliminate things like domain
> checks which depend solely on the range, not the precision.

There's been work on fixed point optimization for embedded DSP that also
propagates precision information.  e.g. we have [min,max,prec] which means
that the value is known to be a multiple of pow(2,prec), as well as being
in [min,max].  The idea is that we want to eliminate both the
overflow-check operations and the rounding operations in generated code.

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Joe Buck]

> None of the papers discussed it in a floating point context, merely from an
> integer context.  The basics were you had a range [min,max] and a bit which
> indicated that the value was in or out of the range which was built up on a
> basic block level for each expression.
> ...
> As you mention it could be used to detect and eliminate things like domain
> checks which depend solely on the range, not the precision.

There's been work on fixed point optimization for embedded DSP that also
propagates precision information.  e.g. we have [min,max,prec] which means
that the value is known to be a multiple of pow(2,prec), as well as being
in [min,max].  The idea is that we want to eliminate both the
overflow-check operations and the rounding operations in generated code.

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[craig]

>It'd be a lot of work though.  I suspect there's other lower hanging fruit
>we can/should go after (assignment motion, partial dead code elimination,
>sparse conditional constant propagation, etc).

No analysis to offer, but: my instincts say you're right.

        tq vm, (burley)

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[craig]

>It'd be a lot of work though.  I suspect there's other lower hanging fruit
>we can/should go after (assignment motion, partial dead code elimination,
>sparse conditional constant propagation, etc).

No analysis to offer, but: my instincts say you're right.

        tq vm, (burley)

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jeffrey A Law]

  In message < 19990305143358.4747.qmail@deer >you write:
  > If that we really true *generally*, i.e. for floating-point as well,
  > then we could happily make -mieee the default for egcs/gcc on Alphas,
  > for example.  (This would make Alpha-generated floating-point code
  > much slower, of course, which is why I mention it: if it was possible
  > to use value-range propagation to determine when the special code-
  > generation normally needed for full IEEE range wasn't needed after all,
  > then some of that performance could be regained.)
None of the papers discussed it in a floating point context, merely from an
integer context.  The basics were you had a range [min,max] and a bit which
indicated that the value was in or out of the range which was built up on a
basic block level for each expression.

The ranges were then propagated through the flow graph like any other local 
local property.  A trivial example, at a flow merge point where we had
one path with a range 0..4 inclusive and a range 6...12 inclusive the
resulting range would be 0..12 inclusive. [ It didn't try to track the hole
at 5. ]


As you mention it could be used to detect and eliminate things like domain
checks which depend solely on the range, not the precision.

Knowing that certain numbers can't be a NaN or Inf would lead to being able
to apply more identity operations on floating point values.

It'd be a lot of work though.  I suspect there's other lower hanging fruit
we can/should go after (assignment motion, partial dead code elimination,
sparse conditional constant propagation, etc).


jeff

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[craig]

>Most of the papers I've read have indicated only trivial gains from value
>range propagation.  I've also had discussions with folks that have implemented
>this opt in a commercial compiler -- it's so minor of a win that they didn't
>consider it worth the effort.

If that we really true *generally*, i.e. for floating-point as well,
then we could happily make -mieee the default for egcs/gcc on Alphas,
for example.  (This would make Alpha-generated floating-point code
much slower, of course, which is why I mention it: if it was possible
to use value-range propagation to determine when the special code-
generation normally needed for full IEEE range wasn't needed after all,
then some of that performance could be regained.)

But, I have to admit I can't document any really clear performance
wins from my own hand-tuned assembly code (written over the past few
decades) deriving solely from value-range propagation, especially
for *integer* (versus floating-point) values.

Generally, I think being able to avoid even checking for exceptional
values might be one source of performance wins from this: e.g. if
we knew it was "impossible" to divide by zero here, square-root a
negative number there, and so on, we could save generated extra
code, thus making Icache misses theoretically less frequent.

        tq vm, (burley)

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jeffrey A Law]

  In message < 9903050403.AA36338@marc.watson.ibm.com >you write:
  > 	GCC is missing a general feature of value propagation which would
  > help with a lot of optimizations like this.  Hopefully this infrastructure
  > will be added or contributed someday.
Most of the papers I've read have indicated only trivial gains from value
range propagation.  I've also had discussions with folks that have implemented
this opt in a commercial compiler -- it's so minor of a win that they didn't
consider it worth the effort.

It's best use appears to be for optimizing array bounds checking in languages
that require such checks.


jeff

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Zack Weinberg]

On Thu, 04 Mar 1999 23:03:58 -0500, David Edelsohn wrote:
>>>>>> Jeffrey A Law writes:
>
>Jeff> True, but I don't believe the loop optimizer is prepared to do that sinc
>e it
>Jeff> doesn't keep track of what bits are active vs what bits are inactive in 
>a 
>Jeff> value.
>
>	GCC is missing a general feature of value propagation which would
>help with a lot of optimizations like this.  Hopefully this infrastructure
>will be added or contributed someday.

For the case I'm interested in, we don't need general value propagation,
only to recognize that we are loading QImode values into a register without
sign extension.  Mode-based range analysis ought to be simpler than full
value propagation.

If we knew how to generate QImode compares, we wouldn't need to clear the
register at all.  That may be something fixable in i386.md, I'm not sure.

zw

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Zack Weinberg]

On Thu, 04 Mar 1999 23:03:58 -0500, David Edelsohn wrote:
>>>>>> Jeffrey A Law writes:
>
>Jeff> True, but I don't believe the loop optimizer is prepared to do that sinc
>e it
>Jeff> doesn't keep track of what bits are active vs what bits are inactive in 
>a 
>Jeff> value.
>
>	GCC is missing a general feature of value propagation which would
>help with a lot of optimizations like this.  Hopefully this infrastructure
>will be added or contributed someday.

For the case I'm interested in, we don't need general value propagation,
only to recognize that we are loading QImode values into a register without
sign extension.  Mode-based range analysis ought to be simpler than full
value propagation.

If we knew how to generate QImode compares, we wouldn't need to clear the
register at all.  That may be something fixable in i386.md, I'm not sure.

zw

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> True, but I don't believe the loop optimizer is prepared to do that since it
Jeff> doesn't keep track of what bits are active vs what bits are inactive in a 
Jeff> value.

	GCC is missing a general feature of value propagation which would
help with a lot of optimizations like this.  Hopefully this infrastructure
will be added or contributed someday.

David

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jeffrey A Law]

  In message < 199903050104.UAA15335@octiron.phys.columbia.edu >you write:
  > A related issue:  I see us generate a lot of code like this for loops over
  > strings:
  > 
  > loop:
  > 	xorl %eax, %eax
  > 	movb (%esi), %al
  > 	incl %esi
  > 	movb %al, (%edi)
  > 	incl %edi
  > 	testl %eax
  > 	jne loop
  > 
  > After the first iteration, the xorl is unnecessary.  We ought to be able to
  > hoist it out of the loop.
True, but I don't believe the loop optimizer is prepared to do that since it
doesn't keep track of what bits are active vs what bits are inactive in a 
value.

jeff

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Zack Weinberg]

On Thu, 4 Mar 1999 22:20:18 +0100, Jamie Lokier wrote:
>> After several day of search I finally find out offending
>> instruction that slow down gzip compiled with egcs-1.1.1/pgcc-1.1.1
>> on PentiumPro 180MHz (132MB RAM) but the result seems crazy to me.
>> 
>> This instruction is:
>> andl $255, %eax
>> in flush_window (util.c) function body (it is inlined from updcrc)
>> 
>> if you manually replace it with
>> movzbl %al, $eax
>> this will boost decompression by 20%.
>
>In the past I have written hand-optimised assembly language, tuned for
>the different x86 families, and I found movzbl to be a very effective
>instruction on the Pentium Pro.  So what you describe sounds correct.
>
>Another is to do xorl %eax,%eax just before loading something into %al.
>That is fast on the PPro too.

A related issue:  I see us generate a lot of code like this for loops over
strings:

loop:
	xorl %eax, %eax
	movb (%esi), %al
	incl %esi
	movb %al, (%edi)
	incl %edi
	testl %eax
	jne loop

After the first iteration, the xorl is unnecessary.  We ought to be able to
hoist it out of the loop.

zw

Re: gcc-2.7 creates faster code than pgcc-1.1.1

[Jamie Lokier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

ôÅÒÅÈÉÎ ÷ÑÞÅÓÌÁ× wrote:
> After several day of search I finally find out offending
> instruction that slow down gzip compiled with egcs-1.1.1/pgcc-1.1.1
> on PentiumPro 180MHz (132MB RAM) but the result seems crazy to me.
> 
> This instruction is:
> andl $255, %eax
> in flush_window (util.c) function body (it is inlined from updcrc)
> 
> if you manually replace it with
> movzbl %al, $eax
> this will boost decompression by 20%.

In the past I have written hand-optimised assembly language, tuned for
the different x86 families, and I found movzbl to be a very effective
instruction on the Pentium Pro.  So what you describe sounds correct.

Another is to do xorl %eax,%eax just before loading something into %al.
That is fast on the PPro too.

-- Jamie

gcc-2.7 creates faster code than pgcc-1.1.1

[Терехин Вячеслав]

As I wrote previously gcc-2.7.2.3 generates faster gzip
than egcs-1.1.1/pgcc-1.1.1 on PentiumPro.
The slowdown is greater than 10% on decompression operation.
This can be easily checked if you have RedHat 5.2.
The shipped gzip is gcc-2.7.2.3 compiled.

After several day of search I finally find out offending
instruction that slow down gzip compiled with egcs-1.1.1/pgcc-1.1.1
on PentiumPro 180MHz (132MB RAM) but the result seems crazy to me.

This instruction is:
andl $255, %eax
in flush_window (util.c) function body (it is inlined from updcrc)

if you manually replace it with
movzbl %al, $eax
this will boost decompression by 20%.

All the below staff is made in gzip-1.2.4a source folder.

$ make CFLAGS="-O6 -mpentiumpro"
$ time ./gzip -cd egcs-1.1.1.tar.gz > /dev/null

real    0m8.047s
user    0m7.970s
sys     0m0.070s

$time ./gzip -c egcs-1.1.1.tar.gz > /dev/null

real    0m12.646s
user    0m12.470s
sys     0m0.160s

$
gcc -c -DASMV -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DDIRENT=1 -O6 -mpentiumpro
util.c -S
$ sed 's/andl $255,%eax/movzbl %al, %eax/g' util.s > util.S
$
gcc -c -DASMV -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DDIRENT=1 -O6 -mpentiumpro
util.S
$ make CFLAGS="-O6 -mpentiumpro"

$ time ./gzip -cd egcs-1.1.1.tar.gz > /dev/null

real    0m6.658s
user    0m6.540s
sys     0m0.110s

$ time ./gzip -c egcs-1.1.1.tar.gz > /dev/null

real    0m12.688s
user    0m12.490s
sys     0m0.180s

All this staff do not apply to Pentium processor as far as I know
(I test it Pentium MMX 200MHz)

I do not know why this happens.
Anybody who knows how to deal with it, please, reply me
as soon as possible.

And finally if you have Pentium Pro or Pentium II please
do this check and report result to me.
I wonder whether I have brain damaged Pentium Pro.

Sincerely Yours, Eugene.


PS I am not on this mailing list.
Also it will be better if you will sent reply to bom@classic.iki.rssi.ru
I can not use it directly as mail can not be delivered by it to this list.