From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <segher@kernel.crashing.org>
Received: from gate.crashing.org (gate.crashing.org [63.228.1.57])
 by sourceware.org (Postfix) with ESMTP id F3E703985C2A
 for <gcc-help@gcc.gnu.org>; Tue,  3 Nov 2020 17:25:41 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F3E703985C2A
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none)
 header.from=kernel.crashing.org
Authentication-Results: sourceware.org;
 spf=fail smtp.mailfrom=segher@kernel.crashing.org
Received: from gate.crashing.org (localhost.localdomain [127.0.0.1])
 by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 0A3HNwVW024450;
 Tue, 3 Nov 2020 11:23:58 -0600
Received: (from segher@localhost)
 by gate.crashing.org (8.14.1/8.14.1/Submit) id 0A3HNvkw024449;
 Tue, 3 Nov 2020 11:23:57 -0600
X-Authentication-Warning: gate.crashing.org: segher set sender to
 segher@kernel.crashing.org using -f
Date: Tue, 3 Nov 2020 11:23:57 -0600
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Henri Cloetens <henri.cloetens@blueice.be>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Issue with reload
Message-ID: <20201103172357.GK2672@gate.crashing.org>
References: <fee290df-5a22-802d-605d-a0a123ae63e2@blueice.be>
 <92aed6b3-c801-438b-29e0-3d6e17d38620@blueice.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <92aed6b3-c801-438b-29e0-3d6e17d38620@blueice.be>
User-Agent: Mutt/1.4.2.3i
X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL,
 KAM_DMARC_STATUS, TXREP, T_SPF_HELO_PERMERROR,
 T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: gcc-help@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-help mailing list <gcc-help.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2020 17:25:43 -0000

Hi Henri,

On Tue, Nov 03, 2020 at 04:25:32PM +0100, Henri Cloetens wrote:
> > 583: r990:SI=zero_extend(r378:SI#0)
> 
> - The statement (r378:SI#0) takes the '0' subreg form reg r378:SI. 
> (shorthand in the reload dump.)

And it doesn't say what mode subreg it is (QImore or HImode here).
There are multiple cases like this, where the abbreviated RTL is not
conclusive (so cannot be parsed back).

> > (define_insn "zero_extendhisi2_internal"
> >   [(set (match_operand:SI 0 "gpc_reg_operand" "=r,r,r")
> >        (zero_extend:SI (match_operand:HI 1 "movhi_operand_0" 
> "Z,C,r")))]
> 
> - However, the predicate "r" in the statement above, does not allow a 
> subreg.

Yes it does.  See register_operand in recog.c for example.  It is of
course possible your gpc_reg_operand doesn't allow it (bad idea, but I
don't know your code).

You would normally start the gpc_reg_operand code with something like

  if (SUBREG_P (op))
    op = SUBREG_REG (op);

(as well as pretty much all other register operand predicates).


Segher