From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124592 invoked by alias); 4 Mar 2015 21:37:26 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 124532 invoked by uid 48); 4 Mar 2015 21:37:23 -0000 From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu Date: Wed, 04 Mar 2015 21:37:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: law at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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-03/txt/msg00534.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65242 --- Comment #6 from Jeffrey A. Law --- So I think two things are coming into play with reproducing these issues. First an inaccurate trunk version #. r221042 is not a trunk commit. I was able to reproduce with r221041 which is a trunk commit. Odds are Matthias typo'd. Second, these issues are highly dependent upon reloads actions which are known to be notoriously difficult to predict and are easily perturbed. So using r221041 or d21bee29dffb3724605183d17983dfc9f0ee6f21 for the GIT folks, I was able to reproduce with the original testcase without problems. There's a few key insns in play here. The most important (from the IRA dump) is: (insn 32 33 128 3 (set (mem/f:DI (plus:DI (reg/f:DI 203 [ this ]) (const_int 9 [0x9])) [6 this_1(D)->MissFile+0 S8 A8]) (reg/f:DI 264)) j.C:84 467 {*movdi_internal64} (nil)) r203 will get a suitable hard register (r25). r264 will not. r264 is set via: (insn 26 18 17 2 (set (reg/f:DI 264) (plus:DI (reg/f:DI 113 sfp) (const_int 51 [0x33]))) j.C:83 81 {*adddi3} (expr_list:REG_EQUIV (plus:DI (reg/f:DI 113 sfp) (const_int 51 [0x33])) (nil))) I'm guessing sfp is a soft frame pointer or some-such eliminable register. Anyway, the REG_EQUIV note for r264 gets shoved into insn 32 resulting in: (insn 32 33 128 3 (set (mem/f:DI (plus:DI (reg/f:DI 25 25 [orig:203 this ] [203]) (const_int 9 [0x9])) [6 this_1(D)->MissFile+0 S8 A8]) (plus:DI (reg/f:DI 1 1) (const_int 51 [0x33]))) j.C:84 467 {*movdi_internal64} (nil)) We record the following reloads: Reload 0: BASE_REGS, RELOAD_FOR_OPADDR_ADDR (opnum = 0), optional, can't combine, secondary_reload_p Reload 1: GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0), optional, can't combine, secondary_reload_p secondary_out_reload = 0 secondary_out_icode = reload_di_store Reload 2: reload_out (DI) = (mem/f:DI (plus:DI (reg/f:DI 25 25 [orig:203 this ] [203]) (const_int 9 [0x9])) [6 this_1(D)->MissFile+0 S8 A8]) NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional reload_out_reg: (mem/f:DI (plus:DI (reg/f:DI 25 25 [orig:203 this ] [203]) (const_int 9 [0x9])) [6 this_1(D)->MissFile+0 S8 A8]) secondary_out_reload = 1 Reload 3: reload_in (DI) = (plus:DI (reg/f:DI 1 1) (mem/u/c:DI (unspec:DI [ (symbol_ref/u:DI ("*.LC4") [flags 0x2]) (reg:DI 2 2) ] UNSPEC_TOCREL) [13 S8 A64])) FLOAT_REGS, RELOAD_FOR_INPUT (opnum = 1), can't combine reload_in_reg: (plus:DI (reg/f:DI 1 1) (const_int 51 [0x33])) Ugh. So many bad things happening here I want to cry. But I'll focus on reload #3, note FLOAT_REGS. In gen_add2_insn we have: (gdb) p debug_rtx (x) (reg:DI 32 0) $107 = void (gdb) p debug_rtx (y) (mem/u/c:DI (unspec:DI [ (symbol_ref/u:DI ("*.LC4") [flags 0x2]) (reg:DI 2 2) ] UNSPEC_TOCREL) [13 S8 A64]) $108 = void Note the register used for X. This is a direct result of FLOAT_REGS as the class for reload #3. So going to the appropriate insn in the MD file we have: (define_insn "*movdi_internal64" [(set (match_operand:DI 0 "nonimmediate_operand" "=Y,r,r,r,r,r,?m,?*d,?*d,r,*h,*h,r,?*wg,r,?*wj,?*wi") (match_operand:DI 1 "input_operand" "r,Y,r,I,L,nF,d,m,d,*h,r,0,*wg,r,*wj,r,O"))] Note carefully the constraints for alternative #7. op0 is "?m" and op1 is "d". The odd offset in the address computation for operand0 causes mem_operand_opr not to match and thus we ultimately target alternative #7. And "d" happens to be FP regs for double values, presumably FLOAT_REGS. And ultimately this causes the ICE when we try to realize the recorded reloads. That seems a particularly bad alternative to select. One could easily argue the constraint for operand 0, alterantive 7 should be "!m". In fact, if I do that, the test passes and a peek at the reloads we generate for the problematical insn look much better. I'm far from a expert in the PPC backend and not confident enough to propose this patch and find other instances that might need similar updates. But perhaps this saves someone else some analysis time.