Re: 2.95, x86: severe performance problems with short arithmetic

[Zack Weinberg <zack@bitmover.com>]

Richard Henderson wrote:
> On Wed, Aug 11, 1999 at 11:29:24AM -0700, Zack Weinberg wrote:
> > At RTL generation time, pretend that there are no HImode operations
> > other than load/store.
> 
> This loses.  I'm not sure of The Cause, if in fact there is a single
> cause, but the overall effect was clear. 
> 
> You can easily test this out for yourself by defining PROMOTE_MODE.

I did.  One problem leaps out at me:  PROMOTE_MODE does math in HImode
and fixes up the registers afterward - for example:

(insn 37 34 38 (parallel[ 
            (set (reg:HI 31)
                (plus:HI (subreg/s/u:HI (reg/v:SI 26) 0)
                    (subreg:HI (reg/v:SI 29) 0)))
            (clobber (reg:CC 17 flags))
        ] ) -1 (nil)
    (nil))

(insn 38 37 40 (parallel[ 
            (set (reg:SI 32)
                (zero_extend:SI (reg:HI 31)))
            (clobber (reg:CC 17 flags))
        ] ) -1 (nil)
    (nil))

which eventually winds up being

        addw    %dx, %ax        # 37    *addhi_1/1              [length = 3]
        movzwl  %ax, %eax       # 40    zero_extendhisi2/1      [length = 3]

in the middle of a loop.  (Same test case as last time, PROMOTE_MODE
copied from i386/os2.h.)

What we actually want is to do everything in SImode until the results
become visible outside a function - returning, or write to memory.

> > For example, we'd produce
> > 
> > (set (reg:SI 21) (extend:SI (mem:HI address)))
> > (set (reg:SI 22) (add (reg:SI 21) (const_int 1)))
> > (set (mem:HI address) (subreg:HI (reg:SI 22) 0))
> > 
> > for an increment of a HImode memory location.
> 
> As opposed to `incw (%eax)'?  Unfriendly.

I thought that inc MEM was discouraged on post-486.

zw