From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 5DFC83858CD1 for ; Mon, 27 Nov 2023 11:31:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5DFC83858CD1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5DFC83858CD1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=68.232.129.153 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701084669; cv=none; b=CvSsx5xQxH+/tyE7Y0+UMtTWtwXdFYlkXxUCTCC5AIgH3XOwuBZDwyI+r2NlztAKr3qPn5xr922VxOGo6NKhUaColuSTRu1Hdea4jE9EYsZPSyZ/fqkopUy6wB499jgkRFVFhhQW1HBR+ZJBNx0GaPnliPd7IPZOxyUlvVqtjqU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701084669; c=relaxed/simple; bh=JGVSqDis+BTFTHOLHEySWmp6wNnQVMvm+9BXa5gLFNc=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=ugzesfG9tVTOgBnQ0Adzozv+/eDHt2/b/PKzIyitqkOirx7VnF+S4wSpi5bTnu8o0OTuC0EMVvQXO/Gl5G5L88/JIzqjeokj1ZrNHJC73fUtcaumol4H7Y3vikBiyzEgHbLto49PiWcf998gnSP/iLsb3ounyJZqCQPqF/HBRYA= ARC-Authentication-Results: i=1; server2.sourceware.org X-CSE-ConnectionGUID: 0N2B1Zm4Try9vCMLCCplpA== X-CSE-MsgGUID: kt8ftCiuRdWvvnnrlQZd2g== X-IronPort-AV: E=Sophos;i="6.04,230,1695715200"; d="scan'208";a="26867256" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 27 Nov 2023 03:31:03 -0800 IronPort-SDR: 7BWV9ofsE48p7/5gp74K+EhWoxlyODBpRJMv/SGDRbyShWllunknOB30yUU4zCYg+nXubclQkw mxLZQ0oI569as/pjj8r9FHxJsjyBMpWoxYjrnYAZ6cEdTSV5WjLdZbS768HlhIhkgvFnIB/f2a z8f7Evan28GrKraUvEQcRspijL8t5KDwn8djNXftQ5Vgs00e0HD+NnAKgUC1bhOZZxI7lDA3/+ /ZIFJ8Rvv/347iMj3ZvaHa4fB22UNRf0oamGxj/lQApObjZwZ2RKHk7EyIL2d33L0s/tQPymK+ 5UE= Message-ID: <2e63f6e7-6a8e-4112-9cdc-aa14fa7c2824@codesourcery.com> Date: Mon, 27 Nov 2023 11:30:58 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFA] New pass for sign/zero extension elimination Content-Language: en-GB To: Jeff Law , "gcc-patches@gcc.gnu.org" CC: Jivan Hakobyan References: <6d5f8ba7-0c60-4789-87ae-68617ce6ac2c@ventanamicro.com> From: Andrew Stubbs In-Reply-To: <6d5f8ba7-0c60-4789-87ae-68617ce6ac2c@ventanamicro.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-12.mgc.mentorg.com (139.181.222.12) To svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_PORT 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: I tried this patch for AMD GCN. We have a similar problem with excess extends, but also for vector modes. Each lane has a minimum 32 bits and GCC's normal assumption is that vector registers have precisely the number of bits they need, so the amdgcn backend patterns have explicit sign/zero extends for QImode and HImode for the instructions that might need it. It would be cool if this pass could eliminate some of those, but at this point I just wanted to check it didn't break anything. Unfortunately I get a crash building libgcc: > during RTL pass: ext_dce > conftest.c: In function 'main': > conftest.c:16:1: internal compiler error: RTL check: expected code 'subreg', have 'reg' in ext_dce_process_uses, at ext-dce.cc:421 > 16 | } > | ^ > 0x8c7aa3 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int, char const*) > /scratch/astubbs/omp/upA/gcnbuild/src/gcc-mainline/gcc/rtl.cc:770 > 0xa76a27 ext_dce_process_uses > /scratch/astubbs/omp/upA/gcnbuild/src/gcc-mainline/gcc/ext-dce.cc:421 > 0x1aeca5c ext_dce_process_bb > /scratch/astubbs/omp/upA/gcnbuild/src/gcc-mainline/gcc/ext-dce.cc:651 > 0x1aeca5c ext_dce > /scratch/astubbs/omp/upA/gcnbuild/src/gcc-mainline/gcc/ext-dce.cc:802 > 0x1aeca5c execute > /scratch/astubbs/omp/upA/gcnbuild/src/gcc-mainline/gcc/ext-dce.cc:868 > Please submit a full bug report, with preprocessed source (by using -freport-bug). > Please include the complete backtrace with any bug report. > See for instructions. > configure:3812: $? = 1 > configure: failed program was: > | /* confdefs.h */ > | #define PACKAGE_NAME "GNU C Runtime Library" > | #define PACKAGE_TARNAME "libgcc" > | #define PACKAGE_VERSION "1.0" > | #define PACKAGE_STRING "GNU C Runtime Library 1.0" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE_URL "http://www.gnu.org/software/libgcc/" > | /* end confdefs.h. */ > | > | int > | main () > | { > | > | ; > | return 0; > | } I have no idea if this is an unhandled case or a case that shouldn't exist, but it's trying to do "SUBREG_BYTE (dst).is_constant ()" for a very simple instruction: (set (reg/i:SI 168 v8) (const_int 0 [0])) This seems pretty basic to me, but there is some hidden complexity. It's possible that the pass has correctly identified that "v8" can hold more that just a single integer: in this case we're using a single lane of a vector register. No extend is needed here though. The register has 2048 bits, but only 32 are active in SImode. Andrew