[Bug rtl-optimization/57231] New: Hoist zero-extend operations when possible

[Bug rtl-optimization/57231] New: Hoist zero-extend operations when possible

[josh.m.conner at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57231

            Bug ID: 57231
           Summary: Hoist zero-extend operations when possible
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: josh.m.conner at gmail dot com

Compiling this code at -O2:

  unsigned char *value;

  unsigned short foobar (int iters)
  {
    unsigned short total;
    unsigned int i;

    for (i = 0; i < iters; i++)
      total += value[i];

    return total;
  }

On ARM generates a zero-extend of total for every iteration of the loop:

  .L3:
        ldrb    r1, [ip, r3]    @ zero_extendqisi2
        add     r3, r3, #1
        cmp     r3, r0
        add     r2, r2, r1
        uxth    r2, r2
        bne     .L3

I believe we should be able to hoist the zero-extend (uxth) after the loop.

Note that although I manifested this for ARM, I believe it's a general case
that would have to be handled by the rtl optimizers.

This shows up in a hot loop of bzip2:

            for (i = gs; i <= ge; i++) {
               UInt16 icv = szptr[i];
               cost0 += len[0][icv];
               cost1 += len[1][icv];
               cost2 += len[2][icv];
               cost3 += len[3][icv];
               cost4 += len[4][icv];
               cost5 += len[5][icv];
            }

[Bug rtl-optimization/57231] Hoist zero-extend operations when possible

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57231

Steven Bosscher <steven at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-05-10
                 CC|                            |steven at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Steven Bosscher <steven at gcc dot gnu.org> ---
Also happens on powerpc-m32:

.L3:
 #   47: %8:SI=zero_extend([%7:SI+%9:SI])
        lbzx 8,7,9       # 47   *rs6000.md:666/1        [length = 4]
 #   51: %9:SI=%9:SI+0x1
        addi 9,9,1       # 51   *addsi3_internal1/2     [length = 4]
 #   49: %10:SI=%10:SI+%8:SI
        add 10,10,8      # 49   *addsi3_internal1/1     [length = 4]
 #   50: %10:SI=zero_extend(%10:HI)
        rlwinm 10,10,0,0xffff    # 50   *rs6000.md:928/2        [length = 4]
 #   80: {pc={(ctr:SI!=0x1)?L55:pc};
 #        ctr:SI=ctr:SI-0x1;
 #        clobber scratch
 #        clobber scratch;}
        bdnz .L3         # 80   *ctrsi_internal1/1      [length = 4]


BTW the add is in SImode and the zero_extend is from HImode to SImode:

%10:SI=%10:SI+%8:SI
%10:SI=zero_extend(%10:HI)

Isn't that effectively a truncation?  If so, then the zero_extend is not
redundant because without it the add may result in wrap-around and give
a different result.

Or perhaps I'm off my rocker today...

[Bug rtl-optimization/57231] Hoist zero-extend operations when possible

[jasonwucj at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57231

Chung-Ju Wu <jasonwucj at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jasonwucj at gmail dot com

--- Comment #2 from Chung-Ju Wu <jasonwucj at gmail dot com> ---
I guess Joshua was thinking about moving the truncation after the loop
because all variables are unsigned and there is no other 'use' of TOTAL
within the loop.

[Bug rtl-optimization/57231] Hoist zero-extend operations when possible

[josh.m.conner at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57231

--- Comment #3 from Joshua Conner <josh.m.conner at gmail dot com> ---
Exactly - there's no need to truncate every iteration, we should be able to
safely do it when the loop is complete.

[Bug rtl-optimization/57231] Hoist zero-extend operations when possible

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57231

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think there are other bugs about promoting things and then truncating only
when needed.  I also think Kai is working on a pass that does that.