From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id EE24939DD7CB for ; Thu, 8 Dec 2022 18:15:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EE24939DD7CB 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-x630.google.com with SMTP id d3so2282400plr.10 for ; Thu, 08 Dec 2022 10:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=yfpvGbkpK5LUJ7yBt+2ZfhCh2jLunTLlyxe67dtCcwk=; b=ERaja7qQ3WEWEF3yT06yLa2ni2MWrboWZoVinCfFPalcTsF9QE3G09wBjjNkfFxW/p GbyDcjbaFhtUb6rdKHv3OeQDz7iCdRajYHrFoyghUafFJJEiwgJhACkUya0YZy85EIiM AajHq/RTmDwSFGGYgyFxdeFzWpXv4cMkI9Qd2wjYT27QCaj1tv1mlIezPiKsyo6PbCCD +c7YMBTEufrlSfezbli3KY1mYtPSElmTaCZKig+2rqkgALhEj9Hmlsg9/ETNtixHit6K oL+fGx2ToAIHeFHT6EmdwDXMkEk8gRq2UtmxWpZRktSpCdokfONuVuYWx6MvYKRms/N7 tcRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references: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=yfpvGbkpK5LUJ7yBt+2ZfhCh2jLunTLlyxe67dtCcwk=; b=1WZJvxJ1XntdTUsceuF5Jq9hHPASxoakf9lJJck0z5mokfsigUDGRVwFA8xCSQjJxr Pl2/7uf53c3T3jmkmZ0R1nqFCSqALFeQp2FSUIUERwocM9N1A7ki10p0UmkAl2/UccrA R4lGaOjRwYnw4x3uKsMi0c7ALq0wlDj0viJ7O5v8IPWbSZvhI4irmCA3H6A8bHxHsPQw pcvqZRQMRvI239h00OD/dM/AIEJucoWMZICPNy5ss7p5+iNT6HqaRt5Gsb5Km+epmEtV DtrvE7up3J630ZQniRa/BTuN+45XFhkMHw0qxZRS1QB086OXVxLCRQwb25gMiwBQhlQx /BAA== X-Gm-Message-State: ANoB5plAuFX2O3IQMChX1RDnj098/yBE/3Bv0gs9OjjgbPAyry5mRUAH 4qVJi/vSNkQ5hNmp2TwR736AeXdb7bo= X-Google-Smtp-Source: AA0mqf6C8H1Z88ZP/8PnEOA+9kqDB72DvtEmohYO/bzoKyRKxXBr79i/Z41OO61R73v2s7dSmw7RxQ== X-Received: by 2002:a05:6a21:3992:b0:a3:7175:fb13 with SMTP id ad18-20020a056a21399200b000a37175fb13mr4265189pzc.55.1670523349090; Thu, 08 Dec 2022 10:15:49 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id 129-20020a620687000000b00574ee8cfdabsm13003904pfg.148.2022.12.08.10.15.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Dec 2022 10:15:48 -0800 (PST) Message-ID: <1953155e-7d64-664b-4b88-2fc4cb33acf7@gmail.com> Date: Thu, 8 Dec 2022 11:15:47 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH] RISC-V: Produce better code with complex constants [PR95632] [PR106602] Content-Language: en-US To: gcc-patches@gcc.gnu.org References: 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.6 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 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 12/8/22 10:53, Palmer Dabbelt wrote: > On Wed, 07 Dec 2022 12:55:17 PST (-0800), rzinsly@ventanamicro.com wrote: >> Due to RISC-V limitations on operations with big constants combine >> is failing to match such operations and is not being able to >> produce optimal code as it keeps splitting them. By pretending we >> can do those operations we can get more opportunities for >> simplification of surrounding instructions. > > I saw Jeff's comments.  This is always the kind of thing that worries > me: we're essentially lying to the optimizer in order to trick it into > generating better code, which might just make it generate worse code. > It's always easy to see a small example that improves, but those could > be wiped out by secondary effects in real code.  So I'd usually want to > have some benchmarking for a patch like this. > > That said, if this is just the standard way of doing things then maybe > it's just fine? Bridge combiner patterns are pretty standard. The insn's condition of cse_not_expected is also in there to minimize the potential for surprises by not exposing this too early. jeff