From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by sourceware.org (Postfix) with ESMTPS id E22403858C20 for ; Sat, 1 Oct 2022 18:58:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E22403858C20 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-x1033.google.com with SMTP id g1-20020a17090a708100b00203c1c66ae3so6884864pjk.2 for ; Sat, 01 Oct 2022 11:58:13 -0700 (PDT) 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; bh=I+M0JLxbBDy1Utofn8rXRNW9u/wFnMOTS3YqNe0RFIQ=; b=YWfxIPj+cnPhFFTx/eHs5cvQMs0vONMzErrNcFIF1KFNBOLUxIVpXlCKqtJk62G90v P0zQWEAcqCUfYoNEKiH65x4YbJC7RtbPL6c7ve13eebIJBlgP7eP27KRBbD8JDJQ8SNV b1Hqc9GhCVCQ0WA7l1iELQh29b447OWHH0UkK80s+973kX8oZ97I5gLL07+Notp6aHd3 Z0lhKke3t2LxFXCqhPlpWWRci5bGvhdb8xYX77gsWNW1LPoqDoWgcoNiTvTYofQmzecC JFgK9jNVrLwOfulsnZNlKG8QPBZy5vqxBNn0YJrrnuHwy3htkXOiQmzoNKTZidfaheAS USxA== 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; bh=I+M0JLxbBDy1Utofn8rXRNW9u/wFnMOTS3YqNe0RFIQ=; b=rdIsf5CYaegs6Vjymh47cOY5BRzPMlgvhXz+wFjgkidJncAW0DBxb5DRZoruqcxHFn YRq2ZVRiPXsBcsFkJ5wpbLExVrymvCWVFjlbK53jG+ndBqpwlDkrLI9xiEJLnBCjyBWu KwB6w6s5fpygRoE8X/JNYdPFbhA5oXBQUwtNTul2qDxCYK4LQZzewFbi0o3DXaS5v0xr xfF6Rb7QBcIgJKW1Dk9M0a4RtEn+5VS8ER1IgI1TfTdtkL2iawONlSPi6hDwqljAGyPP CfXy9ELu9KYWF087n3bwf1kY/ahIgGH8RZ4crqKmVqK7HYMgAKNTqe57fZbRhgbMIPfK I2Ng== X-Gm-Message-State: ACrzQf1G8zzUitcz4JxoX8gvnINbXRw9UVFNP2AKomlgStqbpUo56iKA aaXPl7cJk6etDFigm9DmJACHQBYnm0KFLQ== X-Google-Smtp-Source: AMsMyM6Sl5BS33aWpPkSB7GeDrgdmzsN9Fy4mpOddiIPzWKxl82twRF/FHIvagbMnj4pab1rH6+nWg== X-Received: by 2002:a17:90b:4a4f:b0:202:8d29:c188 with SMTP id lb15-20020a17090b4a4f00b002028d29c188mr4429343pjb.199.1664650692263; Sat, 01 Oct 2022 11:58:12 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id q19-20020aa79833000000b005480167b921sm4206465pfl.172.2022.10.01.11.58.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 01 Oct 2022 11:58:11 -0700 (PDT) Message-ID: <4e31f6ce-9e69-852b-6c0d-161fd9c0d0aa@gmail.com> Date: Sat, 1 Oct 2022 12:58:11 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: [RFA] Avoid unnecessary load-immediate in coremark 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=-4.2 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 9/29/22 01:44, Richard Biener wrote: > On Tue, Sep 27, 2022 at 9:54 PM Jeff Law wrote: >> >> This is another minor improvement to coremark. I suspect this only >> improves code size as the load-immediate was likely issuing with the ret >> statement on multi-issue machines. >> >> >> Basically we're failing to utilize conditional equivalences during the >> post-reload CSE pass. So if a particular block is only reached when a >> certain condition holds (say for example a4 == 0) and the block has an >> assignment like a4 = 0, we would fail to eliminate the unnecessary >> assignment. > conditional equivalences on RTL - ick ;) That was my first reaction as well. > > I'm not familiar with RTL pattern matching so somebody else has to > comment on that, but > > + /* If this is not the first time through, then > + verify the source and destination match. */ > + else if (dest == XEXP (cond, 0) && src == XEXP (cond, 1)) > + ; > > shouldn't you restrict dest/src somehow? It might be a MEM? > The way you create the fake insn suggests only REG_P dest are OK > (not SUBREGs for example?)? You're absolutely right, as is Richard S WRT unexpected sharing. I'll adjust the patch appropriately. > Should you use rtx_equal_p (not using that possibly exempts MEM, > but being more explicit would be nice). Should you restrict this to > MODE_INT compares? rtx_equal_p would be better, yes.  I'll adjust that too. This should work regardless of hte mode type though.  The key is the post-reload cse bits have to check that the pattern matches and that the constraints are satisfied when a replacement is made.   My only concern would be MODE_CC stuff.  I'll think a bit more about that case. Jeff