[Bug target/67383] reload_cse_simplify_operands fails on ARMV7-M

["renlin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

renlin at gcc dot gnu.org changed:

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

--- Comment #5 from renlin at gcc dot gnu.org ---
(In reply to Vladimir Makarov from comment #4)
> I've tried to reproduce it on gcc-4.9 branch as of today but failed.  The
> problem with constraints and overlapped hard regs was probably fixed by
> backported patches.
> 
> Still I have another problem:
> 
> ../lib/mm/mm.c: In function ‘chunk_node’:
> ../lib/mm/mm.c:430:1: internal compiler error: in assign_by_spills, at
> lra-assigns.c:1357
> 0x853dd5 assign_by_spills
>        
> /home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/lra-assigns.c:1357
> 0x854617 lra_assign()
>        
> /home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/lra-assigns.c:1503
> 0x84de9c lra(_IO_FILE*)
>         /home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/lra.c:2388
> 0x80ca16 do_reload
>         /home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/ira.c:5474
> 0x80ca16 rest_of_handle_reload
>         /home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/ira.c:5615
> 0x80ca16 execute
>         /home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/ira.c:5644
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> 
> The problem is in assigning a hard reg to reload pseudo 442 for insns
> 
>          Choosing alt 0 in insn 153:  (0) =&r  (1) %0  (2) r {*arm_adddi3}
>       Creating newreg=441, assigning class GENERAL_REGS to r441
>       Creating newreg=442 from oldreg=268, assigning class GENERAL_REGS to
> r442
>   153: {r441:DI=r441:DI+r442:DI;clobber cc:CC;}
>       REG_DEAD r268:DI
>       REG_UNUSED cc:CC
>       REG_EQUIV [sp:SI+0x10]
>     Inserting insn reload before:
>   642: r441:DI=[sp:SI+0x8]
>   644: r442:DI=r268:DI
>     Inserting insn reload after:
>   643: [sp:SI+0x10]=r441:DI
> 
> We canot use hard reg 0, 1, 2 as they live through insn 153:
> 
>      ...
>   153: {r272:DI=r268:DI+r159:DI;clobber cc:CC;}
>       REG_DEAD r268:DI
>       REG_UNUSED cc:CC
>       REG_EQUIV [sp:SI+0x10]
>       ...
>   159: call [`debug_printf'] argc:0x20
>       REG_DEAD r1:SI
>       REG_DEAD r0:SI
>       REG_DEAD r2:DI
> 
> Hard reg 7 (FP), 9 (thread), 10 (pic), 13 (sp), 15 (pc) are fixed.  So
> we have only one hole for DI value containing 2 regs (4, 5) and pair
> (4,5) is assigned to 441 and there are no regs for 442.


In this particular case, hard register 12 is free, and hard register 11 can be
spilled to accommodate this DImode pseudo register.

However, the target hook HARD_REGNO_MODE_OK rejects register pairs start from
odd number (11 in this case.) So find_hard_regno_for() failed.

I have found r209615 relaxes the target hook. In thumb2 mode, any register pair
is allowed. I have verified, it fix this ICE.


I will do a full regression test first, If no new issues, I will backport it to
branch 4.9
>From gcc-bugs-return-499564-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 14 17:29:38 2015
Return-Path: <gcc-bugs-return-499564-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 76511 invoked by alias); 14 Oct 2015 17:29:38 -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 76482 invoked by uid 48); 14 Oct 2015 17:29:34 -0000
From: "wmi at google dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction
Date: Wed, 14 Oct 2015 17:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.2.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: wmi at google dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67443-4-LNkpjn3va7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67443-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67443-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-10/txt/msg01119.txt.bz2
Content-length: 1288

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

--- Comment #6 from wmi at google dot com ---
(In reply to Dominik Vogt from comment #3)
> I think the Rtl in comment 1 ist correct.  Note that "i" is stored at
> 0x00000000.xx000000 and "j" is stored at 0x00000000.000000xx.  That is the
> reason for the rather confusing mask in insn 9.  Your test program compiles
> and runs fine for me.

I am not familiar with s390 assembly. please correct me if I am wrong:

This is the assembly generated for my testcase:
.globl _Z3fooP1A
        .type   _Z3fooP1A, @function
_Z3fooP1A:
.LFB0:
        larl    %r5,.L3
        mvi     0(%r2),3                // move 0x00000000.00000003 to 0(%r2)
        l       %r1,.L4-.L3(%r5)        // load 0xff000000 to %r1
        n       %r1,0(%r2)              // %r1 = %r1 & 0(%r2) 0x00000000.00000000
        oill    %r1,5                   // %r1 = %r1 | 5 = 0x00000000.00000005
        st      %r1,0(%r2)              // store 0x00000000.00000005 to 0(%r2)
        br      %r14
        .section        .rodata
        .align  8
.L3:
.L4:
        .long   -16777216
        .align  2
        .previous

According to the asm sequence above, the result of a should be:
0x00000000.00000005, but the correct result should be 0x00000000.03000005,
right?