public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jeffreyalaw@gmail.com>
To: gcc-patches@gcc.gnu.org
Subject: Re: [RFC] postreload cse'ing vector constants
Date: Wed, 7 Sep 2022 09:06:46 -0600	[thread overview]
Message-ID: <7ecca009-32ac-3b2f-e552-55414300113e@gmail.com> (raw)
In-Reply-To: <3b0984ef-c532-c29c-732a-1c9b569e134c@linux.ibm.com>



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


  reply	other threads:[~2022-09-07 15:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-07 14:40 Robin Dapp
2022-09-07 15:06 ` Jeff Law [this message]
2022-09-07 15:33   ` Robin Dapp
2022-09-07 15:49     ` Jeff Law
2022-09-08 13:04       ` Robin Dapp
2022-09-27 17:40         ` Robin Dapp
2022-09-27 19:39           ` H.J. Lu
2022-09-28 16:48             ` Robin Dapp
2022-11-03 12:38               ` Robin Dapp
2022-11-20 16:40                 ` Jeff Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7ecca009-32ac-3b2f-e552-55414300113e@gmail.com \
    --to=jeffreyalaw@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).