From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 3BCEE38618D4 for ; Mon, 19 Oct 2020 19:30:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3BCEE38618D4 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 09JJSedJ018063; Mon, 19 Oct 2020 14:28:40 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 09JJSeMl018056; Mon, 19 Oct 2020 14:28:40 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 19 Oct 2020 14:28:39 -0500 From: Segher Boessenkool To: Henri Cloetens Cc: gcc-help@gcc.gnu.org Subject: Re: Issue during combine. Message-ID: <20201019192839.GR2672@gate.crashing.org> References: <2ade57f1-ff38-553c-0e06-1cbb445f5d4e@blueice.be> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2ade57f1-ff38-553c-0e06-1cbb445f5d4e@blueice.be> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, BODY_8BITS, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_SHORT, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 19:30:27 -0000 [ Please don't top-post ] Hi Henri, On Mon, Oct 19, 2020 at 05:55:55PM +0200, Henri Cloetens wrote: > On 10/19/2020 02:53 PM, Henri Cloetens wrote: [ snip ] > >This, of course, is not correct any more. Now, how should I prevent > >this ?, the pattern is defined in the .md-file as: The combiner only ever does transformations that result in recognised instructions, see this code (and many lines before): /* If it still isn't recognized, fail and change things back the way they were. */ if ((insn_code_number < 0 /* Is the result a reasonable ASM_OPERANDS? */ && (! check_asm_operands (newpat) || added_sets_1 || added_sets_2))) { undo_all (); return 0; } > >/(define_insn "movqi_internal" // > >//[(set (match_operand:QI 0 "movqi_operand_0" > >"=r,r,r,r,r,r,u,u,W,t,r,c,*c*l,*h,*h,y")// > >//(match_operand:QI 1 "movqi_operand_1" "O,k,i,r,W,t,W,t,r,r,*h,u, > >r,   r, 0,y"))]/ > > > >/.../ > >and /movqi_operand_1/ is defined as: > > > >/(define_predicate "movqi_operand_1"// > >//  (ior (match_operand 0 "gpc_reg_operand")// > >//       (ior (match_operand 0 > >"quarterword_offset21_memref_operand_or_indirect")// > >//            (match_operand 0 "immediate_operand"))))/ What is quarterword_offset21_memref_operand_or_indirect defined as? > >Any of you any idea why the combine succeeds ?. I mean, it should fail > >!. After combine, it does not match /movqi_internal/ pattern > >any more, but the compiler seems to think otherwise !. Maybe it matches some other pattern? Use -fdump-rtl-combine-all and then look at the RTL dump file: at the end of each function it shows the resulting RTL stream, and each insn like (insn 7 18 8 2 (set (reg:DI 3 3) (plus:DI (reg/f:DI 111 sfp) (const_int 112 [0x70]))) "vlf.c":18:10 69 {*adddi3} (nil)) shows the name of the pattern that matched this (*adddi3 here). > This seems to be a bug in the non-port code of the compiler. > It crashes in > /rtx simplify_subreg(machine_mode outer_mode, rtx op, machine_mode > inner_mode, poly_uint64 byte)/ > > The crash is, because this function is called with inner_mode = > Voidmode. (And seems illegal.) Before you said that bad code was generated, and now you say the compiler crashes. Which is it? > It seems to me this "illegal" mode is the result of the /combine/ step, > trying to "improve" by doing combinations of > instructions "at random". Combine combines instructions that have a (register) dependency. What it comes up with as the combined insn is often not something that the target in fact supports, but that is fine: then that combination is not made. > Here, it tries a "combination" that does not > make sense, but it causes a crash in > the abovementioned routine. Please open a bug report (see for instructions). Thanks in advance! > When I change the code, so that this routine > returns 0 (=fail the operation), it passes > the '263 step without errors. The meaningless combination is refused > elsewhere. It is not done. Btw, those numbers vary over time, and they are different for different targets (combine currently is 265 for x86_64, and 270 for rs6000). Just use the name please :-) Segher