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
next prev parent 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).