public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jeffreyalaw@gmail.com>
To: Robin Dapp <rdapp@linux.ibm.com>, gcc-patches@gcc.gnu.org
Subject: Re: [RFC] postreload cse'ing vector constants
Date: Wed, 7 Sep 2022 09:49:12 -0600	[thread overview]
Message-ID: <5b687817-126e-d463-9d88-b3d7d2dad861@gmail.com> (raw)
In-Reply-To: <70a54b9a-30ea-5673-3a41-9585b3abf627@linux.ibm.com>



On 9/7/2022 9:33 AM, Robin Dapp wrote:
>> 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?
> This one was buried under some dust :)
>
> commit 0254c56158b0533600ba9036258c11d377d46adf
> Author: John Carr <jfc@mit.edu>
> Date:   Wed Jun 10 06:00:50 1998 +0000
>
>      reload1.c (reload_cse_simplify_operands): Do not call gen_rtx_REG
> for each alternative.
>
>      Wed Jun 10 08:56:27 1998  John Carr  <jfc@mit.edu>
>              * reload1.c (reload_cse_simplify_operands): Do not call
> gen_rtx_REG
>              for each alternative.  Do not replace a CONST_INT with a REG
> unless
>              the reg is cheaper.
>
>      From-SVN: r20402
>
> Back then we didn't have vectors I suppose but apart from that I don't
> see a compelling reason not to unconditionally check costs from this.
> It seems like we did even more unconditional replacing before it,
> including CONST_INTs.
Which is this from the mail archives:

https://gcc.gnu.org/pipermail/gcc-patches/1998-June/000308.html

I would tend to agree that for equal cost that the constant would be 
preferred since that should be better from a scheduling/dependency 
standpoint.   So it seems to me we can drive this purely from a costing 
standpoint.

jef

  reply	other threads:[~2022-09-07 15:49 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
2022-09-07 15:33   ` Robin Dapp
2022-09-07 15:49     ` Jeff Law [this message]
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=5b687817-126e-d463-9d88-b3d7d2dad861@gmail.com \
    --to=jeffreyalaw@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rdapp@linux.ibm.com \
    /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).