[Bug target/65326] New: LRA missing a Thumb optimization.

[Bug target/65326] New: LRA missing a Thumb optimization.

[matthew.wahab at arm dot com]

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

            Bug ID: 65326
           Summary: LRA missing a Thumb optimization.
           Product: gcc
           Version: 4.9.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: matthew.wahab at arm dot com

Created attachment 34964
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34964&action=edit
Testcase showing change in behaviour.

The ARM backend no longer supports -mno-lra so only the LRA is available. This
has also removed the Thumb mode optimiziation introduced in
https://gcc.gnu.org/ml/gcc-patches/2005-08/msg01140.html to fix PR 23436.

This turns sequences like
     mov    r3, r9
    mov    r2, r10
    ldr    r0, [r3, r2]
into
    mov    r3, r9
    add    r3, r3, r10
    ldr    r0, [r3]
which saves a register.

Attached is a contrived test case. Compiling with gcc-4.9 with -mthumb -mno-lra 
(at -O1 and higher) produces the second (better) sequence. Compiling with
gcc-4.9 or gcc-trunk with -mthumb (at -O1 and higher) produces the first
sequence. The sequences appear after the 'nop'

gcc-4.9 is 
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20141119
(release) [ARM/embedded-4_9-branch revision 218278]

trunk is:
arm-none-eabi-gcc (unknown) 5.0.0 20150217 (experimental)

[Bug target/65326] LRA missing a Thumb optimization.

[renlin at gcc dot gnu.org]

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

renlin at gcc dot gnu.org changed:

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

--- Comment #1 from renlin at gcc dot gnu.org ---
In this specific case, thumb_legitimize_address will generate ldr r0, [r9, r10]
pattern(after IRA). However, this pattern only allows LO_REGS. During reload, 
r9&r10 will be spilled into LO_REGS, that's where those two mov instructions
come from.

(In reply to Matthew Wahab from comment #0)
> Created attachment 34964 [details]
> Testcase showing change in behaviour.
> 
> The ARM backend no longer supports -mno-lra so only the LRA is available.
> This
> has also removed the Thumb mode optimiziation introduced in
> https://gcc.gnu.org/ml/gcc-patches/2005-08/msg01140.html to fix PR 23436.
> 
> This turns sequences like
>  	mov	r3, r9
> 	mov	r2, r10
> 	ldr	r0, [r3, r2]
> into
> 	mov	r3, r9
> 	add	r3, r3, r10
> 	ldr	r0, [r3]
> which saves a register.
> 
> Attached is a contrived test case. Compiling with gcc-4.9 with -mthumb
> -mno-lra 
> (at -O1 and higher) produces the second (better) sequence. Compiling with
> gcc-4.9 or gcc-trunk with -mthumb (at -O1 and higher) produces the first
> sequence. The sequences appear after the 'nop'
> 
> gcc-4.9 is 
> arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20141119
> (release) [ARM/embedded-4_9-branch revision 218278]
> 
> trunk is:
> arm-none-eabi-gcc (unknown) 5.0.0 20150217 (experimental)
>From gcc-bugs-return-485729-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu May 07 11:40:55 2015
Return-Path: <gcc-bugs-return-485729-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29678 invoked by alias); 7 May 2015 11:40:55 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 29610 invoked by uid 48); 7 May 2015 11:40:49 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0
Date: Thu, 07 May 2015 11:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: WAITING
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: vehre at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65894-4-TNJ59hRPIp@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65894-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65894-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-05/txt/msg00569.txt.bz2
Content-length: 1274

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide894

--- Comment #20 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Patch submitted at:
>
> https://gcc.gnu.org/ml/fortran/2015-05/msg00025.html
>
> This patch also fixes the issue in comment #15.

With the submitted patch I have been able to build the whizard package. The
summary for 'make check' is

===========================================================================Testsuite summary for WHIZARD 2.2.6
===========================================================================# TOTAL: 280
# PASS:  60
# SKIP:  167
# XFAIL: 0
# FAIL:  53
# XPASS: 0
# ERROR: 0

Many failures are of the kind

FAIL: models.run
===============
Running script ./models.run
| Writing log to 'models.log'
| ===========================================================================| Running self-test: models
| ----------------------------------------------------------------------------
Running test: models_1 ... success.
Running test: models_2| Reading model file
'/Users/dominiq/Downloads/whizard-2.2.6/share/models/Test.mdl'
whizard(55852,0x7fff72381300) malloc: *** error for object 0x7fff54a0a5e8:
pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Is this expected?