public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: HAO CHEN GUI <guihaoc@linux.ibm.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>,
	 Segher Boessenkool <segher@kernel.crashing.org>,
	David <dje.gcc@gmail.com>,  "Kewen.Lin" <linkw@linux.ibm.com>,
	Peter Bergner <bergner@linux.ibm.com>,
	 "Vladimir N. Makarov" <vmakarov@redhat.com>
Subject: Re: [PATCH-1, rs6000] Put constant into pseudo at expand when it needs two insns [PR86106]
Date: Thu, 16 Mar 2023 11:36:25 +0100	[thread overview]
Message-ID: <CAFiYyc0frV0NvYTsSdnqqPg60Z4=aHXTkG5BUtexDSyH990z_A@mail.gmail.com> (raw)
In-Reply-To: <4e1f2c62-5f43-a8a1-2c20-8b318520db8e@linux.ibm.com>

On Thu, Mar 16, 2023 at 10:04 AM HAO CHEN GUI <guihaoc@linux.ibm.com> wrote:
>
> Hi Richard,
>
> 在 2023/3/16 15:57, Richard Biener 写道:
> > So this is one way around the lack of CSE/PRE of constant operands.  I'd
> > argue that a better spot for this _might_ be LRA (split the constant out if
> > there's a free register available), postreload-[g]cse (CSE the constants) and
> > then maybe cprop_hardreg to combine back single-use constants?
> >
> > I'm not sure if careful constraints massaging like adding magic letters to
> > alternatives with constants to pessimize them for LRA, making them
> > more expensive than spilling the constant to a register but avoid
> > secondary reloads with spilling a register to the stack to make room
> > for the constant, is possible - but in theory a special constraint modifier
> > for this purpose could be invented.
>
> Thanks so much for your advice.
>
> cse/gcse doesn't take cost of constant set (the def insn of the constant) into
> consideration. So it won't replace the register with a constant as it costs 1
> insn with the register and costs 2 insn with the constant.

I think it does (and should) cost the constant set (IIRC we had some
improvements
there, or at least proposed, during this stage1).  But sure - this is why your
"trick" works.

> Finally, the single-
> use constants can't be back to 2 insn.

And that's because of the issue you point out above?

> Not sure if I understand it correctly.
> Looking forward to your advice.

My main point is that CSEing constants has impacts on register pressure
and thus should probably be done after or within register allocation.  RTL
expansion itself is probably a bad time to pro-actively split out constants
even more if, as you say, nothing puts them back.

Richard.

> Thanks
> Gui Haochen

  reply	other threads:[~2023-03-16 10:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-16  5:34 HAO CHEN GUI
2023-03-16  7:57 ` Richard Biener
2023-03-16  9:04   ` HAO CHEN GUI
2023-03-16 10:36     ` Richard Biener [this message]
2023-03-17  2:48       ` HAO CHEN GUI
2023-03-22  3:08   ` HAO CHEN GUI

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='CAFiYyc0frV0NvYTsSdnqqPg60Z4=aHXTkG5BUtexDSyH990z_A@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=bergner@linux.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=guihaoc@linux.ibm.com \
    --cc=linkw@linux.ibm.com \
    --cc=segher@kernel.crashing.org \
    --cc=vmakarov@redhat.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).