public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Qing Zhao <qing.zhao@oracle.com>
Cc: Richard Biener <richard.guenther@gmail.com>,
	gcc Patches <gcc-patches@gcc.gnu.org>
Subject: Re: HELP: Questions on unshare_expr
Date: Mon, 15 Jan 2024 16:06:03 +0100	[thread overview]
Message-ID: <ZaVJ2z2q+mVPQo39@tucnak> (raw)
In-Reply-To: <EA5C2FB9-AA9A-4F21-8F0D-C0382C4048FB@oracle.com>

On Mon, Jan 15, 2024 at 02:54:26PM +0000, Qing Zhao wrote:
> So, before gimplification,  when inserting tree node, we don’t need manually
>  add unshare_expr since the gimplification will automatically unshare nodes. 

There are cases where unshare_expr is needed even then, such as the uses in
the sanitizer, because code is then modifying suboperands in place later on
and if things are shared bad things happen.  If trees can be shared until
they are unshared before gimplification, one doesn't need to worry about it,
sure.

> However, during or after gimplfication, when inserting nodes, we should manually
>  add unshare_expr when we put the same “tree” into multiple operands.

Yes.

> > Using a SAVE_EXPR avoids redundant code but it also requires
> > that the SAVE_EXPR uses are ordered.
> 
> “Require the SAVE_EXPR uses are ordered”, does this mean that 
> SAVE_EXPRs for the same node should be in a correct order? Or something else?

The basic requirement is that SAVE_EXPR is evaluated somewhere in a code
which dominates all other uses of the SAVE_EXPR.
Say
SAVE_EXPR <something_complex>, if (x) use1 (SAVE_EXPR <something_complex>); else use2 (SAVE_EXPR <something_complex>);
is fine, but
if (x) use1 (SAVE_EXPR <something_complex>); else use2 (SAVE_EXPR <something_complex>);
is not.  Because in the latter case, it will be gimplified into evaluating
the complex expression in the conditional code guarded on if (x != 0), save
into some temporary variable and then in the else code just use that
temporary variable, except it is uninitialized then.

	Jakub


  reply	other threads:[~2024-01-15 15:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-12 15:54 Qing Zhao
2024-01-12 16:28 ` Richard Biener
2024-01-12 17:30   ` Qing Zhao
2024-01-15  8:13     ` Eric Botcazou
2024-01-15 16:42       ` Qing Zhao
2024-01-15  9:31     ` Richard Biener
2024-01-15 14:54       ` Qing Zhao
2024-01-15 15:06         ` Jakub Jelinek [this message]
2024-01-15 16:41           ` Qing Zhao
2024-01-16 20:25       ` Qing Zhao
2024-01-17  6:42         ` Richard Biener
2024-01-17  6:43           ` Richard Biener
2024-01-18 14:45             ` Qing Zhao
2024-01-19  9:30               ` Richard Biener
2024-01-19 16:25                 ` Qing Zhao
2024-01-22  7:40                   ` Richard Biener
2024-01-22 14:52                     ` Qing Zhao
2024-01-22 16:54                       ` Qing Zhao

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=ZaVJ2z2q+mVPQo39@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=qing.zhao@oracle.com \
    --cc=richard.guenther@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).