[Documentation] Correct RTL documentation: (use (mem ...)) is allowed.

[Documentation] Correct RTL documentation: (use (mem ...)) is allowed.

[Roger Sayle]

[-- Attachment #1: Type: text/plain, Size: 778 bytes --]


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.


Roger
--


[-- Attachment #2: patchdo.txt --]
[-- Type: text/plain, Size: 730 bytes --]

diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
index 43c9ee8..995c8be 100644
--- a/gcc/doc/rtl.texi
+++ b/gcc/doc/rtl.texi
@@ -3283,7 +3283,8 @@ Represents the use of the value of @var{x}.  It indicates that the
 value in @var{x} at this point in the program is needed, even though
 it may not be apparent why this is so.  Therefore, the compiler will
 not attempt to delete previous instructions whose only effect is to
-store a value in @var{x}.  @var{x} must be a @code{reg} expression.
+store a value in @var{x}.  @var{x} must be a @code{reg} or a @code{mem}
+expression.
 
 In some situations, it may be tempting to add a @code{use} of a
 register in a @code{parallel} to describe a situation where the value

Re: [Documentation] Correct RTL documentation: (use (mem ...)) is allowed.

[Jeff Law]

On 7/23/22 03:26, Roger Sayle wrote:
> 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.

jeff

Re: [Documentation] Correct RTL documentation: (use (mem ...)) is allowed.

[Uros Bizjak]

> > 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.