From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id 31E27385841A for ; Wed, 7 Sep 2022 15:06:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 31E27385841A 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-pf1-x42a.google.com with SMTP id 123so5530993pfy.2 for ; Wed, 07 Sep 2022 08:06:50 -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=bscM4UGLIn7hObohnQxFu+vomVGr9xCMtDl6gVs0NL0=; b=ZkYbl7s4ulVE+MQ3rmLHSJPghsQYl3mNuNbNg3wjwcIJINYcBZsCxzu3ja78raYgqr hRhqscckRv0tBegA4EGR2VqtsGyFM1n7nA936b7+9BHWEVMVqOxhDiOLbXwwJmMm+QM/ /w6jpis9Cm2LhOI/89RlE8SdOTzUQ73F/9EBld9BVpUiQTQd9RkFoQbTGl+46WiBSwBZ R/QR5H420jD8TWYv/LvQocKPnO1wFEE/O70CP2ZTlVxu2JaP8Vs7rIypJ6FrC0zufxG/ BjAd/8iaqwbAwK2swOmZlEjBawVSbZ1MI50NR+Mw/rt6ZToCX8R7YZVwyanCOx1UOkJt KbMw== 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=bscM4UGLIn7hObohnQxFu+vomVGr9xCMtDl6gVs0NL0=; b=L4TfJdO+WofsZ44Qb3OGfQpxPI6FnyqLHl/PynRMnWjJV3iPGpBoaDOg/0861WiNpN j6FAutSoIvpw5w/Q1We61Xv+dKSOS+8iVviyTQZc7j2jWFVprmvh/qPcz2z0qlrAL2/s s+oleDU9sp3ienGnvQKBUDfTYZKP+t/ibyUbTeBqYqfotLGLr5F7tn0iDaOVVYbg5XMy 2qSnhxq0OFEd7YXGw1iUV+HBBH2OTxJZWfjVbuXV6pub3OLiHXc6flBgefn+YDc0mt7V Tv7Yq+w0SLifwwWTvrpuLs5feN6QF7lsNDRh5DbA7HedZdM3xOehDFHi8Ao7KcBZUei6 H9Tg== X-Gm-Message-State: ACgBeo31uFmZEuD5RnBOpSXWTb2wn2Zf2hC8QUGmjLCuYwBVcXJNpAV3 /9dUE798Dp7D0MRM5LYgo3Q+5t4Dz1Zinw== X-Google-Smtp-Source: AA6agR7AOtw0r43blKYkKj50Nb9GtPCbtLrpTz0Fdqxm/AihDZvbXFG4MTWYQJ2/pcykrOQ58kBxwQ== X-Received: by 2002:a63:81c6:0:b0:42b:c3fa:3a0 with SMTP id t189-20020a6381c6000000b0042bc3fa03a0mr3939536pgd.72.1662563208380; Wed, 07 Sep 2022 08:06:48 -0700 (PDT) Received: from [172.31.0.204] (c-73-98-188-51.hsd1.ut.comcast.net. [73.98.188.51]) by smtp.gmail.com with ESMTPSA id x2-20020a17090a0bc200b00200461cfa99sm7374163pjd.11.2022.09.07.08.06.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Sep 2022 08:06:47 -0700 (PDT) Message-ID: <7ecca009-32ac-3b2f-e552-55414300113e@gmail.com> Date: Wed, 7 Sep 2022 09:06:46 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [RFC] postreload cse'ing vector constants Content-Language: en-US To: gcc-patches@gcc.gnu.org References: <3b0984ef-c532-c29c-732a-1c9b569e134c@linux.ibm.com> From: Jeff Law In-Reply-To: <3b0984ef-c532-c29c-732a-1c9b569e134c@linux.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.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 9/7/2022 8:40 AM, Robin Dapp via Gcc-patches wrote: > Hi, > > I recently looked into a sequence like > > vzero %v0 > vlr %v2, %v0 > vlr %v3, %v0. > > Ideally we would like to use vzero for all of these sets in order to not > create dependencies. > > For some instances of this problem I found the offending snippet to be > the postreload cse pass. If there is a non hard reg whose value is > equivalent to an existing hard reg, it will replace the non hard reg. > The costs are only compared if the respective operand is a CONST_INT_P, > otherwise we always replace. > > The comment before says: > /* See if REGNO fits this alternative, and set it up as the > > > replacement register if we don't have one for this > > > alternative yet and the operand being replaced is not > > > a cheap CONST_INT. */ > > Now, in my case we have a CONST_VECTOR consisting of CONST_INTS (zeros). > This is obviously no CONST_INT therefore the substitution takes place > resulting in a "vlr" instead of a "vzero". > Would it not make sense to always compare costs here? Some backends have > instructions for loading vector constants and there could also be > backends able to load floating point constants directly. > > For my snippet getting rid of the CONST_INT check suffices because the > costs are similar and no replacement happens. Was this originally a > shortcut for performance reasons? I thought we were not checking that > many alternatives and only locally at this point anymore. > > Any comments or ideas? It looks sensible to me.  ISTM this should be driven by costs, not by any particular rtx codes.  Your patch takes things in the right direction. Did you did any archeology into this code to see if there was any history that might shed light on why it doesn't just using the costing models? jeff