public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Uros Bizjak <ubizjak@gmail.com>
To: Jeff Law <jeffreyalaw@gmail.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [Documentation] Correct RTL documentation: (use (mem ...)) is allowed.
Date: Wed, 28 Sep 2022 11:38:25 +0200	[thread overview]
Message-ID: <CAFULd4YH3m83MjGCsrNQX46P48-g120tveFUWZwP7gA68J1VVw@mail.gmail.com> (raw)
In-Reply-To: <0b5d2b5d-fccb-ff3d-d1cc-5276e914f6da@gmail.com>

> > This patch is a one line correction/clarification to GCC's current
> > RTL documentation that explains a USE of a MEM is permissible.
> >
> > PR rtl-optimization/99930 is an interesting example on x86_64 where
> > the backend generates better code when a USE is a (const) MEM than
> > when it is a REG. In fact the backend relies on CSE to propagate the
> > MEM (a constant pool reference) into the USE, to enable combine to
> > merge/simplify instructions.
> >
> > This change has been tested with a make bootstrap, but as it might
> > provoke a discussion, I've decided to not consider it "obvious".
> > Ok for mainline (to document the actual current behavior)?
> >
> >
> > 2022-07-23  Roger Sayle   <roger@nextmovesoftware.com>
> >
> > gcc/ChangeLog
> >          * doc/rtl.texi (use): Document that the operand may be a MEM.
>
> Given this is documenting existing behavior and it's not hard to
> envision the MEM being useful in this context.  OK.

I would like to point out at this occasion that there are some issues
with (use (mem)) when commutative operands are used. PR95218 has a
testcase where the postreload pass simply removed the instruction (see
comment #6). It was later found out in comment #17 that commutative
operands in (use (...)) statements somehow confuse postreload pass. I
have to remove commutative operands from (use (...)) to solve the
issue, so either this unfortunate fact should be mentioned in the
documentation or the limitation (bug?) should be fixed in the
postreload pass.

Uros.

      reply	other threads:[~2022-09-28  9:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-23  9:26 Roger Sayle
2022-09-27 15:13 ` Jeff Law
2022-09-28  9:38   ` Uros Bizjak [this message]

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=CAFULd4YH3m83MjGCsrNQX46P48-g120tveFUWZwP7gA68J1VVw@mail.gmail.com \
    --to=ubizjak@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.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).