From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by sourceware.org (Postfix) with ESMTPS id B87523860757 for ; Thu, 7 Dec 2023 12:11:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B87523860757 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 B87523860757 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::12a ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701951078; cv=none; b=rajoEo/ziIGZrxnMEKkvjXcgYaEYUnJPhQcrqZ4Z9ujywWNKX/XCZ7jujwpqhJioaWYsPO8uSZt2mnJYw/BysyLW5qyo+veBpneiW9IjCtfOhwEkwxtseFUuywAfAMbvS+N7+qTdPfqIgZi+DW1H3vaFD+JYWaKmSmI8XocfJz0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701951078; c=relaxed/simple; bh=UDNEoksmcY7iI25fcE16ZWL+9DROm9Xno+lfzX10qXk=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=iQ/aGUEBEAvcLqeTleZ5Xdq32xl6IvktCbF4aC45FGRCOb4op1n3OKjK38YZs8Ptmh3DanmHyQpSyXQCjt6x/31JJl2FbxMD6dzEh7s5QnhFlQ492TcqfjpxDhCvojbnRfN8jxcj+rj4shWIV8Z/drkG1WOXQdmD2+bMIArPpkk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-50be3611794so661213e87.0 for ; Thu, 07 Dec 2023 04:11:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701951066; x=1702555866; 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=lCteRwbiSDLy/u04hSJ6i3gsYt5OFwlPt211qREamw8=; b=Itt/8oWuM6VWfHX/0MolCYP7qcnpPW3R3Khdsa+aNeWlhGoijPrmQ2U6ZQsTyxOK8K RPDHGzbMLuWj+0pVMDNtF1CWBkEpQ4uh+sLanuJ/QfvdBj7o2lckEe5ts6blAsYW8WSF 387cPcuFkWt9iMU1E0BMbxHdqESljXQotX+IT5Au8X8IySpIhgt/l1ga6gfUs28Mv4gx IDcgxbDXnC0Yvx2Oc2/z4S8TdDUrD+IXaI4o/Oxn6ulBCMILV/u7In3Xe6TttO61st2W 8AEOezZ0SbtLg3tm9asxuzLzjqVCI6T+nCwkry1+8iizZwZjkeG9vfhNNFUnP6faa+Ds fG3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701951066; x=1702555866; 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=lCteRwbiSDLy/u04hSJ6i3gsYt5OFwlPt211qREamw8=; b=eM+VUoEbzC57Iq/nSlELtHMW5Ja46x9pwwn7Hc2mGc94yHISm5cm2frZoPI8FRPs72 Yi1+X1ccnvxFiIMEB1d4xw6zpnilPvq20XEQeyzeUlNzlV6jczqJ/VAkg3efLEqeGDoF FnWg4/xM2Q9T/pj3iG0F/iMd5lyHQhhemLbkhuRJ/8nQuwJ70YItm14P+XM5Y88CBSuC zvC6xQEjJsH3PT2rX7cDwbzP8WoVRsKJByOL1PA0n8djzlBrhWA+wLoQV2FwF4B3x2HJ /du1HSv1TnfaTk2J/tp83NNrhrMYo5QxJVvI27fIFBeDz5YGHP1w/dUqQL5BoNpO4I7C ewDQ== X-Gm-Message-State: AOJu0Yzl9dNTQgjRcPECEh50XNaNKFCBEJ4DAvBXI+aUTMUwMGvZlhOf GV6iz+CHdusw8/SHsgunkH6BgjzY2OcTNBKBnXE= X-Google-Smtp-Source: AGHT+IG9gkdIBeCTOItAqFC8VTd5JxdcV4T26HQ0RJdgY9ChOtLCDW0HoVqwHF0eyokT6EbWJI4rR9rjFBy+tBwFkn8= X-Received: by 2002:a05:6512:3b8d:b0:50b:f326:5ae5 with SMTP id g13-20020a0565123b8d00b0050bf3265ae5mr1850046lfv.102.1701951065772; Thu, 07 Dec 2023 04:11:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Thu, 7 Dec 2023 13:09:57 +0100 Message-ID: Subject: Re: [PATCH] combine: Fix ICE in try_combine on pr112494.c [PR112560] To: Uros Bizjak Cc: Segher Boessenkool , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_PORT 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 Mon, Dec 4, 2023 at 10:34=E2=80=AFAM Uros Bizjak wro= te: > > On Wed, Nov 29, 2023 at 1:25=E2=80=AFPM Richard Biener > wrote: > > > > On Wed, Nov 29, 2023 at 10:35=E2=80=AFAM Uros Bizjak wrote: > > > > > > The compiler, configured with --enable-checking=3Dyes,rtl,extra ICEs = with: > > > > > > internal compiler error: RTL check: expected elt 0 type 'e' or 'u', > > > have 'E' (rtx unspec) in try_combine, at combine.cc:3237 > > > > > > This is > > > > > > 3236 /* Just replace the CC reg with a new mode. */ > > > 3237 SUBST (XEXP (*cc_use_loc, 0), newpat_dest); > > > 3238 undobuf.other_insn =3D cc_use_insn; > > > > > > in combine.cc, where *cc_use_loc is > > > > > > (unspec:DI [ > > > (reg:CC 17 flags) > > > ] UNSPEC_PUSHFL) > > > > > > combine assumes CC must be used inside of a comparison and uses XEXP = (..., 0) > > > without checking on the RTX type of the argument. > > > > > > Skip the modification of CC-using operation if *cc_use_loc is not COM= PARISON_P. > > > > > > PR middle-end/112560 > > > > > > gcc/ChangeLog: > > > > > > * combine.cc (try_combine): Skip the modification of CC-using > > > operation if *cc_use_loc is not COMPARISON_P. > > > > > > Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}. > > > > > > OK for master? > > > > Don't we need to stop the attempt to combine when we cannot handle a us= e? > > Simply not adjusting another use doesn't look correct, does it? > > I have analysed [1] all targets that define SELECT_CC_MODE, and almost > all use CC_REG exclusively in comparison. Besides i386 that defines: > > (define_insn "@pushfl2" > [(set (match_operand:W 0 "push_operand" "=3D<") > (unspec:W [(match_operand:CC 1 "flags_reg_operand")] > UNSPEC_PUSHFL))] > > other non-comparison pre-reload uses of CC_REG are: > > arm: > > (define_insn "get_fpscr_nzcvqc" > [(set (match_operand:SI 0 "register_operand" "=3Dr") > (unspec_volatile:SI [(reg:SI VFPCC_REGNUM)] UNSPEC_GET_FPSCR_NZCVQC))] > > (define_insn "mve_vadcq_v4si" > [(set (match_operand:V4SI 0 "s_register_operand" "=3Dw") > (unspec:V4SI [(match_operand:V4SI 1 "s_register_operand" "w") > (match_operand:V4SI 2 "s_register_operand" "w")] > VADCQ)) > (set (reg:SI VFPCC_REGNUM) > (unspec:SI [(reg:SI VFPCC_REGNUM)] > VADCQ)) > ] > > rs6000: > > (define_insn "prologue_movesi_from_cr" > [(set (match_operand:SI 0 "gpc_reg_operand" "=3Dr") > (unspec:SI [(reg:CC CR2_REGNO) (reg:CC CR3_REGNO) > (reg:CC CR4_REGNO)] > UNSPEC_MOVESI_FROM_CR))] > > and just for reference s390: > > (define_insn_and_split "*ccraw_to_int" > [(set (pc) > (if_then_else > (match_operator 0 "s390_eqne_operator" > [(reg:CCRAW CC_REGNUM) > (match_operand 1 "const_int_operand" "")]) > (label_ref (match_operand 2 "" "")) > (pc))) > (set (match_operand:SI 3 "register_operand" "=3Dd") > (unspec:SI [(reg:CCRAW CC_REGNUM)] UNSPEC_CC_TO_INT))] > > The above is not single_use, so the issue does not apply here. > > These uses can all break with checking enabled at the mentioned spot > in combine.cc in the same way as x86. Actually, it is undesirable to > change the mode in the "other instruction" - the machine instruction > doesn't care about mode at all, but the insn pattern may fail > recognition due to CC mode change. > > Based on the above analysis, I propose we proceed with my original patch. I'm not familiar enough with combine nor CC reg uses to approve the patch (I just wanted to point out what I noticed when browsing patches). I'll de= fer to Segher for approval. Thanks, Richard. > [1] Starting with 'egrep -v -w "set|clobber" *.md | grep ' and > analysing all hits > > Uros.