From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id 72B8B3858D35 for ; Thu, 7 Mar 2024 22:47:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 72B8B3858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 72B8B3858D35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::236 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709851631; cv=none; b=vQJarTlRdBGT3rxKl20yJvqVIkatTh7vkHhj+XUxMnFnZ2h8CgEHeZq0l3rg2b00ln1r5JBRmiouVUrBybQUhtmWdCFcMywqKADY/sd1xGSPdlwbxosfl0OTLwz2PIGhTKR6KHL1lUKQSRhsiVCuDRoz4DaUblZIcaq62ejewPk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709851631; c=relaxed/simple; bh=tKC2Gy6cV4Zz04YhUKkbpj+mwGif8Os48+mQJcnTH/U=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=GgM3IjEhhL+s3x5xtON0yJuJwU7lM8kcijaYQuyDEwMMg4hBkKg/Wn6Y6NfVXW9Oj4gQrQAojRvJIC3bhMXET/SvnGHNq1l2eVNdyRft6jTf8oX0dRFMtUxEY4lXOx7WKqu85SB/xKbtIxl2vwDRBLsNsWSGWJGC9H0QSsN9yxQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2d28051376eso2324001fa.0 for ; Thu, 07 Mar 2024 14:47:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709851627; x=1710456427; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=6yJ/Y4IA4EdbfNWYJRChC1V2BO+k8Du7mUnRpqjekz8=; b=I24cUGrDCg82v5+B54WHkXwejv4d8hVssgMpd5xUTYfSkYozu0RDLJ76SHUFxdFaSs goSZJMHARxNWS/d1crybsLmgLSjRWVpmb9WCeDCE8O5ryAicSzVZi7ecO62GVx9ODN2s RJfyl+2ozQ1BWhqmMjoZEmoQ8te+XIMq9nb7WOJJTKUXIumOcTkfqyrAxONhJ0q8u/EF P4HfsVS+vToEj6mpZK0KdcIKDbRuBnYm4lMJUpQ1m/3zX1MotjG4IxhnxVfSUbeR81lK tl4vGiHBS8RUwmGPnHmGyvw5M3GEhl9IrC2xTrdq3wUz0jeYg81IHA/ZVo8JRbLeTEtF jNzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709851627; x=1710456427; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6yJ/Y4IA4EdbfNWYJRChC1V2BO+k8Du7mUnRpqjekz8=; b=fUrKjtze0MaIyyeiTAQpdVta2zRBf/6Ieract5D5fzMNqwf4QETaTjZdZw6caQ//Cu iZRULcs0SnDJ3Bpe7K1/W+m27jg5xempIFqhUFnKzcPq29DR1NL4dHeTYdLNG+RGihDf 6PxL8RlN/uV2/fgVcp2TaWyYVeC8bTgEDm31q1p2fevcMZ9F3oVDz2H16lUKD6J0f6hj 3+LNnd65cZhj4pxLEO1YnFdtJRPCS8wK/P3nfz/PYGIpyEuvwOsJh8TyJqHwZtFYseyk 9+ekUDTd6Ls6f5XT6Qm+PSDD+JGEuR2dYxpuOB+LKPQe6lHYhzkc1kwmaZrw2vl1Ise9 3i7w== X-Forwarded-Encrypted: i=1; AJvYcCW8JRUDrTcWW7s8i7jLQziKY8EvWuUp0qWL9jV3RN24vCKUe85M2tEqygx0BYnCPHPHTHd/Ao5YT0BQezn89l37vIyOyCpO/g== X-Gm-Message-State: AOJu0YzOszBA6/tnYHBaBR+DmsZRt8Frzj3Ed8U7ZCz1X10D7VXExiR5 PFKBXkzCl5Q9USLOu2vpg9q+T6eYuZ+uGJqFYjmfMR1goc1T1mO8G9RaAixdVI3DYoFY1wPWry2 Hgk7UGMvBFVkCUu5RmXIa873PT2Y= X-Google-Smtp-Source: AGHT+IGxqAW3aJTLlK2Ri8LeFSr+tB3p5yzCuIhPqcc27ZKM6QSx0vPNAflOOGwneJf55ua2LHMsTx6U0UgKGsD0ZO0= X-Received: by 2002:a2e:8045:0:b0:2d3:5ddc:b949 with SMTP id p5-20020a2e8045000000b002d35ddcb949mr2171097ljg.2.1709851626701; Thu, 07 Mar 2024 14:47:06 -0800 (PST) MIME-Version: 1.0 References: <2737spr1-459p-3oon-n852-qn034s55p66r@fhfr.qr> <20240307173659.GH19790@gate.crashing.org> <20240307213551.GL19790@gate.crashing.org> <20240307222711.GP19790@gate.crashing.org> In-Reply-To: <20240307222711.GP19790@gate.crashing.org> From: Uros Bizjak Date: Thu, 7 Mar 2024 23:46:54 +0100 Message-ID: Subject: Re: [PATCH v2] combine: Fix ICE in try_combine on pr112494.c [PR112560] To: Segher Boessenkool Cc: Richard Biener , "gcc-patches@gcc.gnu.org" , Jeff Law Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham 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 7, 2024 at 11:29=E2=80=AFPM Segher Boessenkool wrote: > > On Thu, Mar 07, 2024 at 11:07:18PM +0100, Uros Bizjak wrote: > > On Thu, Mar 7, 2024 at 10:37=E2=80=AFPM 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=3D112494#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 pushfl can be considered as a transparent move, separate bits have no meaning there. I don't see why using unspec should be any different than using "naked" register (please also see below, current source code may update "naked" reg as well). What constitutes use is "(cmp:CC (CC reg) (const_int 0))" around the register and I think that without this RTX around the CC reg its use should not be updated in any way. > > > > The source code that deals with the *user* of the CC register assum= es > > > > 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. Previously, it was defined as: (define_insn "*pushfl2" [(set (match_operand:W 0 "push_operand" "=3D<") (match_operand:W 1 "flags_reg_operand"))] But Wmode, AKA SI/DImode is not CCmode. And as said in my last message, nothing prevents current source code to try to update the CC register here. Uros.