From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-448503-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 2779 invoked by alias); 8 Apr 2014 06:42:02 -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
Received: (qmail 2718 invoked by uid 48); 8 Apr 2014 06:41:57 -0000
From: "rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
Date: Tue, 08 Apr 2014 06:42: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: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rsandifo at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60763-4-WSZ1zttDy1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60763-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60763-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: 2014-04/txt/msg00523.txt.bz2

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

--- Comment #11 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to David Edelsohn from comment #10)
> I'm not questioning the analysis, I'm questioning the solution. Directly
> generating a register and jamming in the REGNO in this pattern seems sort of
> crude.
> 
> gen_rtx_REG (DImode, REGNO (op0));
> 
> I don't doubt that this is the RTL that eventually is produced, I am
> surprised that there is no existing wrapper function in simplify-rtx.c or
> rtlanal.c that can be used.
> 
> If this is the necessary implementation, I think it deserves some, brief
> comment.

I think the reason there's no wrapper function is that it's very dangerous
to change the mode of a register when the target has explicitly said that
that shouldn't happen.

Maybe it's an easier sell if I say that this op0_di is really a secondary
temporary value that just happens to use the same register as the output.
I think:

(define_insn_and_split "reload_vsx_from_gprsf"
  [(set (match_operand:SF 0 "register_operand" "=wa")
    (unspec:SF [(match_operand:SF 1 "register_operand" "r")]
           UNSPEC_P8V_RELOAD_FROM_GPR))
   (clobber (match_operand:DI 2 "register_operand" "=r"))
   (clobber (match_operand:DI 3 "register_operand" "=wa"))]
  "TARGET_POWERPC64 && TARGET_DIRECT_MOVE"
  "#"
  "&& reload_completed"
  [(const_int 0)]
{
  rtx op0 = operands[0];
  rtx op1 = operands[1];
  rtx op2 = operands[2];
  rtx op3 = operands[3];
  rtx op1_di = simplify_gen_subreg (DImode, op1, SFmode, 0);

  /* Move SF value to upper 32-bits for xscvspdpn.  */
  emit_insn (gen_ashldi3 (op2, op1_di, GEN_INT (32)));
  emit_move_insn (op3, op2);
  emit_insn (gen_vsx_xscvspdpn_directmove (op0, op3));
  DONE;
}
  [(set_attr "length" "8")
   (set_attr "type" "two")])

would work too.  The difference is that the above would always allocate
two separate FPRs, which is wasteful, so the pattern is trying to use
the same register for both the temporary value and the final result.

But I suppose it just doesn't seem that crude to me.