From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 782EA3858D28 for ; Mon, 31 Jul 2023 23:50:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 782EA3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-1b9c5e07c1bso43413705ad.2 for ; Mon, 31 Jul 2023 16:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690847418; x=1691452218; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=nPIXyQJvxDYK4Gi7Pok2uMU8L1Q2nVz4PWFFf2o7lkk=; b=YiTbk/OVPFYp57U7QtpazkcztB1xDhV5lCDok4ENtKxgiCgt4IcbfoV1FvTah6ykTx IldjFJ0df/nhq2LtadYW6/5x+UKwbFyiaJLsWSTvW1hcVNfJZemxtZColYY61YZCVVxO U7wGWcD4bOXkDR+Jf+h63hmCkxsQrm8GFWCWE/hMQgZNOpllYYaSqhVoGLyred/MjrRc VhQs2P6v5yDRjZCVERav93gxX8QM/EE0LsB2ak0A/hQwIFU76P16di1wdjsK+jEAixh4 wMTkcF8ZPkHh7Xnfv+CN/UM8V7i9BsEmIIAD4BE1MGcr8Ihe0EXXaMJCN7GckcrDE2vX oLLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690847418; x=1691452218; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nPIXyQJvxDYK4Gi7Pok2uMU8L1Q2nVz4PWFFf2o7lkk=; b=DCH6RrgZ/Wh7HLmsnJEXNg9ViyTXVvSVW9WObYPAdY0cMp7B2bfra2ndokr6Px62S2 nKqADFJHgTD4U01dAmWWdVli274qAic5wl/qxLEZKhWxJZxFyGC1IFtJVVxJ1q+HGkwO 7RiOcXCf5x2Uij7D9Zc2QVHObnTBFTR6lxsfaRQpDlOE/BsfjxIGq1uuyg4nyf7KWiqV lyP1qOtuqdJuYOxBnPOSQURpWW3EHaim0TXzO5b2CNQJHi657uqW4q4vkw4T16tranpL jxA/z57oRaNdHFUzLWfcqdyr/K4QgXiU1gwGBZ9DFElDiXeekSH8N376w2/Fj8ygLG89 b3gw== X-Gm-Message-State: ABy/qLZGfnHKaoTGBtVJzkyfpFUkVthEGb1UY6uvovHQmyTmu7ZcYG9v vm/bBJxNfcLyfFkkjarp1ww= X-Google-Smtp-Source: APBJJlFydTLQPZEI/IpQAdo6dRm7upxIrZWgdn6Li53i1r5/hs/mvRAg8KFp7I2PXTAskuiMoIBePg== X-Received: by 2002:a17:902:ea0d:b0:1b3:d4d5:beb2 with SMTP id s13-20020a170902ea0d00b001b3d4d5beb2mr14807823plg.9.1690847417635; Mon, 31 Jul 2023 16:50:17 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id iy7-20020a170903130700b001b898595be7sm9085793plb.291.2023.07.31.16.50.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Jul 2023 16:50:17 -0700 (PDT) Message-ID: <0d598847-2fb0-7ee3-db3c-259632c9a91a@gmail.com> Date: Mon, 31 Jul 2023 17:50:15 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v2] combine: Narrow comparison of memory and constant Content-Language: en-US To: Prathamesh Kulkarni , Stefan Schulze Frielinghaus Cc: gcc-patches@gcc.gnu.org References: <20230619142356.345159-1-stefansf@linux.ibm.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,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 7/31/23 15:43, Prathamesh Kulkarni via Gcc-patches wrote: > On Mon, 19 Jun 2023 at 19:59, Stefan Schulze Frielinghaus via > Gcc-patches wrote: >> >> Comparisons between memory and constants might be done in a smaller mode >> resulting in smaller constants which might finally end up as immediates >> instead of in the literal pool. >> >> For example, on s390x a non-symmetric comparison like >> x <= 0x3fffffffffffffff >> results in the constant being spilled to the literal pool and an 8 byte >> memory comparison is emitted. Ideally, an equivalent comparison >> x0 <= 0x3f >> where x0 is the most significant byte of x, is emitted where the >> constant is smaller and more likely to materialize as an immediate. >> >> Similarly, comparisons of the form >> x >= 0x4000000000000000 >> can be shortened into x0 >= 0x40. >> >> Bootstrapped and regtested on s390x, x64, aarch64, and powerpc64le. >> Note, the new tests show that for the mentioned little-endian targets >> the optimization does not materialize since either the costs of the new >> instructions are higher or they do not match. Still ok for mainline? > Hi Stefan, > Unfortunately this patch (committed in 7cdd0860949c6c3232e6cff1d7ca37bb5234074c) > caused the following ICE on armv8l-unknown-linux-gnu: > during RTL pass: combine > ../../../gcc/libgcc/fixed-bit.c: In function ‘__gnu_saturate1sq’: > ../../../gcc/libgcc/fixed-bit.c:210:1: internal compiler error: in > decompose, at rtl.h:2297 > 210 | } > | ^ > 0xaa23e3 wi::int_traits >> ::decompose(long long*, unsigned int, std::pair machine_mode> const&) > ../../gcc/gcc/rtl.h:2297 [ ... ] Yea, we're seeing something very similar on nios2-linux-gnu building the kernel. Prathamesh, can you extract the .i file for fixed-bit on armv8 and open a bug for this issue, attaching the .i file as well as the right command line options necessary to reproduce the failure. THat way Stefan can tackle it with a cross compiler. Thanks, jeff