public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Jeff Law <jeffreyalaw@gmail.com>
Cc: Richard Biener <rguenther@suse.de>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Improve DSE to handle stores before __builtin_unreachable ()
Date: Sun, 25 Jun 2023 18:33:43 +0200	[thread overview]
Message-ID: <ZJhsZ5FOGL+jnHLG@kam.mff.cuni.cz> (raw)
In-Reply-To: <ad374587-251f-2db2-34a7-92a2dbe7712b@gmail.com>

> > Also as discussed some time ago, the volatile loads between traps has
> > effect of turning previously pure/const functions into non-const which
> > is somewhat sad, so it is still on my todo list to change it this stage1
> > to something more careful.   We discussed internal functions trap_store
> > and trap_load which will expand to load/store + trap but will make it
> > clear that side effect does not count to modref.
> It's been a long time since I looked at this code -- isn't it the case that
> we already must have had a load/store and that all we've done is change its
> form (to enable more DCE) and added the volatile marker?
> 
> Meaning that it couldn't have been pure/cost before, could it?  Or is it the
> case that you want to not have the erroneous path be the sole reason to
> spoil pure/const detection -- does that happen often in practice?

I noticed that while looking into cases during GCC bootstrap where
function analysis went worse after inlning than before, so it happens
in practice.

mod-ref can now analyse independently whether function reads/wrotes
memory (and what memory) and whether function has other side effects or
is non-deterministics.  We can now DSE function call if it has no side
effects and all memory stores are understood and dead.

Problem is that split paths turns undefined behaivour into side effects
and blocks this optimization.

Honza

  reply	other threads:[~2023-06-25 16:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230620070009.C11983858D1E@sourceware.org>
2023-06-20 13:27 ` Jeff Law
2023-06-21  6:41   ` Richard Biener
2023-06-21  9:55     ` Jan Hubicka
2023-06-21 14:04     ` Jeff Law
2023-06-22  6:31       ` Richard Biener
2023-06-22 13:36         ` Jeff Law
2023-06-22 13:42           ` Jan Hubicka
2023-06-24 14:24             ` Jeff Law
2023-06-25 16:33               ` Jan Hubicka [this message]
2023-06-26 17:21   ` Jan Hubicka
2023-06-26 22:37     ` Jeff Law
2023-06-20  6:59 Richard Biener

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=ZJhsZ5FOGL+jnHLG@kam.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=rguenther@suse.de \
    /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).