[Bug target/94643] New: [x86_64] gratuitous sign extension of nonnegative value from 32 to 64 bits

[Bug target/94643] New: [x86_64] gratuitous sign extension of nonnegative value from 32 to 64 bits

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94643

            Bug ID: 94643
           Summary: [x86_64] gratuitous sign extension of nonnegative
                    value from 32 to 64 bits
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

Test case:

#include <stdint.h>
uint16_t a[];
uint64_t f(int i)
{
        return a[i]*16;
}

Produces:

        movslq  %edi, %rdi
        movzwl  a(%rdi,%rdi), %eax
        sall    $4, %eax
        cltq
        ret

The value is necessarily in the range [0,1M) (in particular, nonnegative) and
operation on eax has already cleared the upper bits of rax, so cltq is
completely gratuitous. I've observed the same in nontrivial examples where
movslq gets used.

[Bug tree-optimization/94643] [sign extension of nonnegative value from 32 to 64 bits

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94643

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
           Keywords|                            |missed-optimization
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-04-18
            Summary|[x86_64] gratuitous sign    |[sign extension of
                   |extension of nonnegative    |nonnegative value from 32
                   |value from 32 to 64 bits    |to 64 bits
           Severity|normal                      |enhancement
          Component|target                      |tree-optimization

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This could be done on the tree level:
Given (where _1 is short unsigned):
  _2 = (int) _1;
  _3 = _2 * 16;
  _6 = (uint64_t) _3;

We should be able to convert this to:
_7 = (uint64_t) _1;
_6 = _7 << 4;

But there might be a few steps inbetween.  I will let someone decide on how it
would work.
This is true even on AARCH64:
        adrp    x1, a
        add     x1, x1, :lo12:a
        ldrh    w0, [x1, w0, sxtw 1]
        ubfiz   x0, x0, 4, 16
        ret

But ubfiz is the the zero extend and shift in one instruction so it does not
matter in the end ...