[Bug target/60778] New: shift not folded into shift on x86-64

[Bug target/60778] New: shift not folded into shift on x86-64

[sunfish at mozilla dot com]

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

            Bug ID: 60778
           Summary: shift not folded into shift on x86-64
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sunfish at mozilla dot com

On this C code:

double mem[4096];
double foo(long x) {
  return mem[x>>3];
}

GCC emits this x86-64 code:

        sarq    $3, %rdi
        movsd   mem(,%rdi,8), %xmm0

The following x86-64 code would be preferrable:

        andq    $-8, %rdi
        movsd   mem(%rdi), %xmm0

since it has smaller code size, and avoids using a scaled index which costs an
extra micro-op on some microarchitectures.

The same situation arrises on 32-bit x86 also.

This was observed on all GCC versions currently on the GCC Explorer website
[0], with the latest at this time being 4.9.0 20130909.

[0] http://gcc.godbolt.org/

[Bug target/60778] shift not folded into shift on x86-64

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-*, i?86-*-*
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-04-08
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  A bit difficult since

(insn 7 6 8 2 (parallel [
            (set (reg:DI 89 [ D.1754 ])
                (ashiftrt:DI (reg/v:DI 86 [ x ])
                    (const_int 3 [0x3])))
            (clobber (reg:CC 17 flags))
        ]) t.i:3 532 {*ashrdi3_1}
     (nil))
(insn 8 7 9 2 (set (reg:DF 90)
        (mem:DF (plus:DI (mult:DI (reg:DI 89 [ D.1754 ])
                    (const_int 8 [0x8]))
                (reg/f:DI 88)) [2 mem S8 A64])) t.i:3 128 {*movdf_internal}
     (nil))

don't combine well (and:DI is not valid inside the MEM), but a
define-insn-and-split may be able to handle this.

[Bug target/60778] shift not folded into shift on x86-64

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2014-04-08 00:00:00         |2021-9-26

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Trying 7 -> 8:
    7: {r87:DI=r89:DI>>0x3;clobber flags:CC;}
      REG_DEAD r89:DI
      REG_UNUSED flags:CC
    8: r88:DF=[r87:DI*0x8+`mem']
      REG_DEAD r87:DI
Failed to match this instruction:
(set (reg:DF 88 [ mem[_1] ])
    (mem:DF (plus:DI (and:DI (reg:DI 89)
                (const_int -8 [0xfffffffffffffff8]))
            (symbol_ref:DI ("mem") [flags 0x2]  <var_decl 0x7f6b6efd9c60 mem>))
[1 mem[_1]+0 S8 A64]))

We have 2->2 combine now but it looks like we don't try to split inside a mem
...

[Bug target/60778] shift not folded into shift on x86-64

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Andrew Pinski from comment #2)
> Trying 7 -> 8:
>     7: {r87:DI=r89:DI>>0x3;clobber flags:CC;}
>       REG_DEAD r89:DI
>       REG_UNUSED flags:CC
>     8: r88:DF=[r87:DI*0x8+`mem']
>       REG_DEAD r87:DI
> Failed to match this instruction:
> (set (reg:DF 88 [ mem[_1] ])
>     (mem:DF (plus:DI (and:DI (reg:DI 89)
>                 (const_int -8 [0xfffffffffffffff8]))
>             (symbol_ref:DI ("mem") [flags 0x2]  <var_decl 0x7f6b6efd9c60
> mem>)) [1 mem[_1]+0 S8 A64]))
> 
> We have 2->2 combine now but it looks like we don't try to split inside a
> mem ...

This address looks similar to how Alpha implemented unaligned load. It looks
like combine tries to synthesize AND address.

[Bug target/60778] shift not folded into shift on x86-64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > Trying 7 -> 8:
> >     7: {r87:DI=r89:DI>>0x3;clobber flags:CC;}
> >       REG_DEAD r89:DI
> >       REG_UNUSED flags:CC
> >     8: r88:DF=[r87:DI*0x8+`mem']
> >       REG_DEAD r87:DI
> > Failed to match this instruction:
> > (set (reg:DF 88 [ mem[_1] ])
> >     (mem:DF (plus:DI (and:DI (reg:DI 89)
> >                 (const_int -8 [0xfffffffffffffff8]))
> >             (symbol_ref:DI ("mem") [flags 0x2]  <var_decl 0x7f6b6efd9c60
> > mem>)) [1 mem[_1]+0 S8 A64]))
> > 
> > We have 2->2 combine now but it looks like we don't try to split inside a
> > mem ...
> 
> This address looks similar to how Alpha implemented unaligned load. It looks
> like combine tries to synthesize AND address.

That is from the (x >> 3) * 8.  Perhaps a combine splitter that will tell
combine that it should split it at the AND?  Though, not sure if the cost will
say that it is beneficial.

[Bug target/60778] shift not folded into shift on x86-64

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #4)
> > > We have 2->2 combine now but it looks like we don't try to split inside a
> > > mem ...
> > 
> > This address looks similar to how Alpha implemented unaligned load. It looks
> > like combine tries to synthesize AND address.
> 
> That is from the (x >> 3) * 8.  Perhaps a combine splitter that will tell
> combine that it should split it at the AND?  Though, not sure if the cost
> will say that it is beneficial.

Maybe we should allow AND addresses and split AND out in
ix86_legitimize_address?