[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

["dcb314 at hotmail dot com" <gcc-bugzilla@gcc.gnu.org>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4477 bytes --]

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

--- Comment #32 from David Binderman <dcb314 at hotmail dot com> ---
Same error with gcc trunk, dated 20131215, for attached
source code.

Flags -O3 -g -fPIC -fstack-protector-strong required.

[dcb@zippy4 foundBugs]$ ../results/bin/gcc -c -O3 -g -fPIC
-fstack-protector-strong bug126.c
zprime.c: In function ‘zfactor’:
zprime.c:577:1: internal compiler error: in vt_expand_var_loc_chain, at
var-tracking.c:8213
0xd1b1d0 vt_expand_var_loc_chain
    ../../src/trunk/gcc/var-tracking.c:8213
0xd1b5c7 vt_expand_loc_callback
    ../../src/trunk/gcc/var-tracking.c:8409
0x6d44de cselib_expand_value_rtx_1
    ../../src/trunk/gcc/cselib.c:1684
0x6d44de cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
    ../../src/trunk/gcc/cselib.c:1531

...
>From gcc-bugs-return-437839-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 17 13:08:15 2013
Return-Path: <gcc-bugs-return-437839-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10468 invoked by alias); 17 Dec 2013 13:08:15 -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 10421 invoked by uid 48); 17 Dec 2013 13:08:11 -0000
From: "rearnsha at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/59535] [4.9 regression] -Os code size regressions for Thumb1/Thumb2 with LRA
Date: Tue, 17 Dec 2013 13:08: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: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rearnsha at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-59535-4-KhO79eWVjW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59535-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59535-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: 2013-12/txt/msg01494.txt.bz2
Content-length: 1705

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY535

--- Comment #6 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Created attachment 31457
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id1457&actioníit
Another testcase

Another testcase, but this one has some obvious examples of poor behaviour for
-Os.

In addtion to the options used on the previous case, this might need
-fno-strict-aliasing -fno-common -fomit-frame-pointer -fno-strength-reduce

Example one, spilling a value and then keeping a copy in a hard reg over a
call.

    mov    r5, r1          <= R1 copied to R5
    sub    sp, sp, #28
    str    r1, [sp, #8]    <= And spilled to the stack
    mov    r2, #12
    mov    r1, #0
    mov    r4, r0
    bl    memset
    mov    r3, #2
    mov    r2, r5          <= Could reload from the stack instead

Example two, use of multiple reloads to use high register:

    ldr    r3, [sp, #4]
    mov    ip, r3          <= Copying value into high register
    add    ip, ip, r5      <= Arithmetic
    mov    r3, ip          <= Copying result back to original register
    str    r3, [sp, #4]
    ldr    r3, [sp, #12]
    mov    ip, r3          <= And IP is dead anyway...

In this case,
    mov    ip, r3
    add    ip, ip, r5
    mov    r3, ip

can be replaced entirely with
    add    r3, r5
saving two completely unnecessary MOV instructions.

Third, related case,

    mov    r1, #12
    mov    ip, r1
    add    ip, ip, r4
    mov    r1, ip

Could be done either as
    mov    r1, #12
    add     r1, r4
    mov    ip, r1
or
    mov    r1, r4
    add    r1, #12
    mov    ip, r1

both saving one instruction, or even two if the value doesn't really need
copying to a high reg.