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 48D4C3857705 for ; Thu, 7 Mar 2024 22:28:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 48D4C3857705 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 48D4C3857705 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=63.228.1.57 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709850495; cv=none; b=rDrm4d7hlEpIB2v7ImWr5uC1Id/63Ck4yu8jYz5KiijUiaVk1/Yt6w1Tu9n76t2BiqcyovxdX8mD6AO8ld5/e+rsj9LEUrQdVRr5MeckpN1LgHf9b5UN1+BzKIeOBRAk1E9SqJo5nDpq1BjfA2p/SmSA8naAfD+hnrSeVx92KcI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709850495; c=relaxed/simple; bh=BK/lfm3fpzvnrwYQE5wfopGf9pBYTzGoUWxUGYvQ+go=; h=Date:From:To:Subject:Message-ID:Mime-Version; b=Cozu78uQm/Oy8PtIG5PF0dGhlssAmjpEwCL8RVbF7PDy5q5m5E7m1G0Jq1nNzS0S3dvpLD1zirOH23lQjTj5PWFRPpVsqgutJSZttPGwMGK4GupyqzFfPgNjpbbn20Ap1FOfHpAUlEkYKmES67MQ0hNvvwGSK2VC/s2m+jnjS+A= ARC-Authentication-Results: i=1; server2.sourceware.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 427MRBUj020346; Thu, 7 Mar 2024 16:27:11 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 427MRBnb020345; Thu, 7 Mar 2024 16:27:11 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 7 Mar 2024 16:27:11 -0600 From: Segher Boessenkool To: Uros Bizjak Cc: Richard Biener , "gcc-patches@gcc.gnu.org" , Jeff Law Subject: Re: [PATCH v2] combine: Fix ICE in try_combine on pr112494.c [PR112560] Message-ID: <20240307222711.GP19790@gate.crashing.org> References: <2737spr1-459p-3oon-n852-qn034s55p66r@fhfr.qr> <20240307173659.GH19790@gate.crashing.org> <20240307213551.GL19790@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Mar 07, 2024 at 11:07:18PM +0100, Uros Bizjak wrote: > On Thu, Mar 7, 2024 at 10:37 PM Segher Boessenkool > wrote: > > > but can be something else, such as the above noted > > > > > > (unspec:DI [ > > > (reg:CC 17 flags) > > > ] UNSPEC_PUSHFL) > > > > But that is invalid RTL? The only valid use of a CC is written as > > cc-compared-to-0. It means "the result of something compared to 0, > > stored in that cc reg". > > > > (And you can copy a CC reg around, but that is not a use ;-) ) > > How can we describe a pushfl then? (unspec:DI [ (compare:CC) ((reg:CC 17 flags) (const_int 0)) ] UNSPEC_PUSHFL) or something like that? > It was changed to its current form > in [1], but I suspect that the code will try to update it even when > pushfl is implemented as a direct move from a register (as was defined > previously). > > BTW: Unspecs are used in a couple of other places for other targets [2]. > > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494#c5 > [2] https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639743.html There is nothing wront with unspecs. You cannot use a CCmode value without comparing it to 0, though. The exact kind of comparison determines what bits are valid (and have what meaning) in your CC reg, even! > > > The source code that deals with the *user* of the CC register assumes > > > the former form, so it blindly tries to update the mode of the CC > > > register inside LT comparison RTX > > > > Would you like it better if there was an assert for this? There are > > very many RTL requirements that aren't chacked for currently :-/ > > In this case - yes. Assert signals that something is unsupported (or > invalid), way better than silently corrupting some memory, reporting > the corruption only with checking enabled. Yeah. The way RTL checking works makes this hard to do in most cases. Hrm. (It cannot easily look at context, only inside of the current RTX). > > The unspec should have the CC compared with 0 as argument. > > But this does not do what pushfl does... It pushes the register to the stack. Can't you just describe the dataflow then, without an unspec? An unspec by definition does some (unspecified) operation on the data. Segher