From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by sourceware.org (Postfix) with ESMTPS id 34D7E383A0E9 for ; Wed, 7 Dec 2022 21:13:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 34D7E383A0E9 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-pj1-x1036.google.com with SMTP id e7-20020a17090a77c700b00216928a3917so2625758pjs.4 for ; Wed, 07 Dec 2022 13:13:52 -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=2I8fQD1tA947JbKjOGKF4CeY8EN2GTCe7zeeTnVjmlw=; b=Ch3RMdRva+0ak/pLmenPGO3ZN5MRXUOfsvjvG0aCbwvYvYq0BuzrBMf5V9F3ZbkIr4 ErDXq/IufNJcae3H1enZaN3PSqWtGMNVjO0r+ipFlu50enDswMvxopZT+tP0vBc2UeUK rFKjDvv5InH3MnXppoiMQ9gunlYPlJiRJfmlBXBCoSdSSEjZcgb7Dvqmj8r190TRQbO0 lVH7ODWiss1UNbwKdfzV/hTCZ0FQ3iqFygyvusAK92P9xoqVQExG+5P5J10CoVISf7vf M+JxJW/P8TIqdz0x3KsLf9KD4vseikL0v4K7lhzaKjIgYN2UNdYI41XSOsJnkRGdamnY 9faw== 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=2I8fQD1tA947JbKjOGKF4CeY8EN2GTCe7zeeTnVjmlw=; b=0i3FrVhIpfVrBzppfPSXedYrZWzcz91PIma7XTlUzSYHLELHG9Z2AmHJWA/rXEBi2P /BFjzebmfS9fUDYJfbEZpAqOp45OtGCa2O1Kf/VS/FER3otiB7WOVHCRBGbovSdnxS+Z rp24Iw08+UBMUuIJffmxyMjLMK5Xs45YDNudfhxr1EjB/t/Wdo+J+qpXnYpAGXSaueVk bqM4rJEk5iXfuYPPqo2odXEKAGuwcwr0LbIoEuvG/udReG9nBSfsrj3tg8YBCK4bQ82r UiQ2mcbXdN4d7YU0y76JFrGTb1GKxm0qDOCNQUEcBcdOYHZsURLt4NKh6KPHKS5CJQMK 8ndw== X-Gm-Message-State: ANoB5pk1vKtcWe93Txv+NuBea6lcUbi53/NEa+O7haXKfzaT9wD2o5hv mG1AGjAM8nHgN+LXe8/TeqcMAVE43wc= X-Google-Smtp-Source: AA0mqf5AoRge3dFOIYDDF+Uu420Bn2an6M/eUb1+Z8c7XlRPNctvskM7tJVwIUb2U2Mh6AAhRDiHiA== X-Received: by 2002:a17:90a:af84:b0:218:c8fd:c213 with SMTP id w4-20020a17090aaf8400b00218c8fdc213mr1057968pjq.36.1670447630127; Wed, 07 Dec 2022 13:13:50 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id h8-20020a17090a710800b0020bfd6586c6sm1597915pjk.7.2022.12.07.13.13.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Dec 2022 13:13:49 -0800 (PST) Message-ID: <1d4f48d9-479e-5ce1-8941-fd5386210278@gmail.com> Date: Wed, 7 Dec 2022 14:13:48 -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: <20221207205517.526182-1-rzinsly@ventanamicro.com> From: Jeff Law In-Reply-To: <20221207205517.526182-1-rzinsly@ventanamicro.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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,KAM_SHORT,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/7/22 13:55, Raphael Moreira Zinsly 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. > > 2022-12-06 Raphael Moreira Zinsly > Jeff Law > > gcc/Changelog: > PR target/95632 > PR target/106602 > * config/riscv/riscv.md: New pattern to simulate complex > const_int loads. > > gcc/testsuite/ChangeLog: > * gcc.target/riscv/pr95632.c: New test. > * gcc.target/riscv/pr106602.c: Likewise. So to give a little background to others. The core issue is that when we break down constants early, it can make it difficult for combine to reconstruct the constant and simplify code using the reconstructed constant -- you end up trying to do 4->3 or worse combination sequences which aren't supported by the combiner. Usually this kind of scenario is handled with a "bridge" pattern. Those are generally defined as patterns that exist solely for combine and may not correspond to any real instruction on the target. "bridge" patterns are typically 2->1 or 3->1 combinations and are intermediate steps for 4->N or even larger combination opportunities. Obviously if the bridge doesn't allow subsequent simplifications, then the bridge pattern must generate correct code (either by generating suitable assembly or splitting later). Raphael's patch introduces a bridge pattern that pretends we can load up splittable constants in a single insn. We restrict the bridge pattern to be active from the point when CSE is no longer expected through the combiner up to the first splitter pass (where we'll break it down again if it's still in the IL). So we get most of the benefit of splitting constants early (CSE, LICM, etc) while also getting the benefits of splitting late (combine simplifications). Given I was working with Raphael on the patch, it's probably best for someone else to do the review rather than me approving it :-) Jeff