target/7056: [ARM] zero extend code worse in 3.1 than 3.0

target/7056: [ARM] zero extend code worse in 3.1 than 3.0

[pb]

>Number:         7056
>Category:       target
>Synopsis:       [ARM] zero extend code worse in 3.1 than 3.0
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          pessimizes-code
>Submitter-Id:   net
>Arrival-Date:   Mon Jun 17 06:16:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     pb@nexus.co.uk
>Release:        gcc-3.1
>Organization:
>Environment:
arm-linux
>Description:
See code below.

With gcc-3.0 -O2, this yields

        stmfd   sp!, {r4, lr}
        ldrb    r3, [r0], #1    @ zero_extendqisi2
        ldrb    r4, [r0, #0]    @ zero_extendqisi2
        mov     r0, r3
        bl      g
        mov     r0, r4
        @ Sibcall epilogue
        ldmfd   sp!, {r4, lr}
        b       g

With gcc-3.1, there is an extra, redundant, AND instruction:

        stmfd   sp!, {r4, lr}
        ldrb    r3, [r0], #1
        and     r3, r3, #255
        ldrb    r4, [r0, #0]    @ zero_extendqisi2
        mov     r0, r3
        bl      g
        mov     r0, r4
        @ Sibcall epilogue
        ldmfd   sp!, {r4, lr}
        b       g
>How-To-Repeat:
void f(unsigned char *p)
{
  unsigned long int a,b;
 
  a = *p++;
  b = *p++;

  g(a);
  g(b);
}
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:

Re: target/7056: [ARM] zero extend code worse in 3.1 than 3.0

[Richard Earnshaw]

The following reply was made to PR target/7056; it has been noted by GNATS.

From: Richard Earnshaw <rearnsha@arm.com>
To: pb@nexus.co.uk
Cc: gcc-gnats@gcc.gnu.org, Richard.Earnshaw@arm.com, jakub@gcc.gnu.org,
        mark@codesourcery.com
Subject: Re: target/7056: [ARM] zero extend code worse in 3.1 than 3.0 
Date: Mon, 17 Jun 2002 16:21:06 +0100

 This was caused by Jakub's patch to fix pr/6086, hence the CC list.  
 
 I think his patch is papering over a symptom rather than fixing the real 
 problem in reload.  That is, if you are going to allow
 
 	(subreg (mem))
 
 at all, then reload must handle it correctly, even if the mem has 
 side-effects.  In this case we should be making reload correctly spill the 
 mem, rather than preventing the above RTL if the mem has side-effects.
 
 For a RISC architecture, like the PPC, I don't think it makes sense to 
 allow subreg-mem in the first place.  The ARM doesn't and I've generally 
 found this to lead to better code than allowing it and then letting reload 
 fix up the problems.
 
 In general these problems seem to come about because register_operand() 
 allows subreg(reg-or-mem) and that seems daft.
 
 R.