[Bug target/61142] New: [SH] QImode/HImode @(R0,Rm),Rn does not load to Rn = R0

[Bug target/61142] New: [SH] QImode/HImode @(R0,Rm),Rn does not load to Rn = R0

[olegendo at gcc dot gnu.org]

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

            Bug ID: 61142
           Summary: [SH] QImode/HImode @(R0,Rm),Rn does not load to Rn =
                    R0
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: olegendo at gcc dot gnu.org
            Target: sh*-*-*

I've noticed that @(R0,Rm),Rn loads won't load into Rn = R0.
Example:

int test0 (const char* x, int a, int b, int c)
{
  if (x[a] == 92)
    return b;
  return c;
}

With -O2 -m4 -ml compiles to:
        mov     r5,r0
        mov.b   @(r0,r4),r1  <<<<
        mov     r1,r0        <<<<
        cmp/eq  #92,r0
        bt      .L3
        mov     r7,r0
        rts
        nop
    .align 1
.L3:
        rts
        mov     r6,r0

This happens for QImode and HImode loads.  SImode is fine.

I'm not sure whether it's a side effect of the changes done for PR 50751, or
something else.

It could be worked around with a peephole, but then we'd waste one register.

[Bug target/61142] [SH] QImode/HImode @(R0,Rm),Rn does not load to Rn = R0

[olegendo at gcc dot gnu.org]

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

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-05-10
         Depends on|                            |55212
     Ever confirmed|0                           |1

--- Comment #1 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Should re-visit this after trying switching to LRA (PR 55212).

[Bug target/61142] [SH] QImode/HImode @(R0,Rm),Rn does not load to Rn = R0

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo <olegendo at gcc dot gnu.org> ---
I've tried the above test case with LRA on (sh-lra branch, not fully working
yet) and it produces the following code:

        mov     r5,r0
        mov.b   @(r0,r4),r0
        cmp/eq  #92,r0
        bt      .L3
        mov     r7,r0
        rts
        nop
    .align 1
.L3:
    rts
    mov     r6,r0

i.e. the problem is gone.

[Bug target/61142] [SH] QImode/HImode @(R0,Rm),Rn does not load to Rn = R0

[olegendo at gcc dot gnu.org]

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

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #3 from Oleg Endo <olegendo at gcc dot gnu.org> ---
While working on adding some patterns for PR 64345, the issue got even worse. 
The problem in the description is just the tip of the iceberg.  For the time
being a bunch of peephole patterns can be used to limit the damage.  The
peepholes that I've added also seem to improve code when LRA is used.

[Bug target/61142] [SH] QImode/HImode @(R0,Rm),Rn does not load to Rn = R0

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Created attachment 34839
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34839&action=edit
A set of peepholes

This is a set of peepholes I have accumulated, although untested.
With the patch CSiBE (-O2 -m4-single -mpretend-cmove) shows the following
summary:

sum:  3371887 -> 3367967    -3920 / -0.116255 %
avg: -217.777778 / -0.167780 %
max: replaypc-0.4.0.preproc   57212 -> 57188          -24 / -0.041949 %
min: mpeg2dec-0.3.1           54348 -> 53984         -364 / -0.669758 %

[Bug target/61142] [SH] QImode/HImode @(R0,Rm),Rn does not load to Rn = R0

[olegendo at gcc dot gnu.org]

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

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #34839|0                           |1
        is obsolete|                            |

--- Comment #5 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Created attachment 34860
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34860&action=edit
A set of peepholes

Testing has revealed that the peephole2 patterns in attachment 34839 produce
wrong code.  If the patterns hit automodify mems the replacement insns of the
peephole2 patterns will not contain any REG_INC notes.  The peephole2 pass does
not copy those notes, but it seems following passes rely on them.

[Bug target/61142] [SH] QImode/HImode @(R0,Rm),Rn does not load to Rn = R0

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Author: olegendo
Date: Thu Feb 26 19:14:23 2015
New Revision: 221026

URL: https://gcc.gnu.org/viewcvs?rev=221026&root=gcc&view=rev
Log:
gcc/
    PR target/61142
    * config/sh/sh.c (sh_check_add_incdec_notes): New function.
    * config/sh/sh-protos.h (sh_check_add_incdec_notes): Declare it.
    * config/sh/predicates.md (const_logical_operand): New predicate.
    * config/sh/sh.md: Add new peephole2 patterns.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/sh/predicates.md
    trunk/gcc/config/sh/sh-protos.h
    trunk/gcc/config/sh/sh.c
    trunk/gcc/config/sh/sh.md

[Bug target/61142] [SH] QImode/HImode @(R0,Rm),Rn does not load to Rn = R0

[olegendo at gcc dot gnu.org]

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

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Fixed on GCC 5 with some workaround peepholes.