public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/109112] [[assume(...)]] is not taken into account for structs
Date: Fri, 14 Jul 2023 12:48:35 +0000	[thread overview]
Message-ID: <bug-109112-4-hxaf23nF6U@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-109112-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109112

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #7)
> Why don't the existing optimizations work on the artificial function the
> same as any other function?  i.e. like
> 
> struct S { bool x; };
> void do_something();
> inline void assumption_1 (const S& s) noexcept {
>   if (s.x) __builtin_unreachable ();
> }
> void fn(S s) {
>   assumption_1 (s);
>   if (s.x) do_something();
> }
> 
> which is also optimized as expected.

Because the assumptions have different representation in the IL.
While normal calls look like:
  ret = foo (arg1, arg2, arg3);
and we can inline those etc., because the assumptions potentially contain
side-effects which shouldn't be evaluated and therefore should e.g. not be
inlined nor assumed that they are actually called, the representation is like:
  .ASSUME (&foo, arg1, arg2, arg3);
where foo is that artificial assumption function which takes arg1, arg2, arg3.
The above behaves like if (!foo (arg1, arg2, arg3)) __builtin_unreachable ();
except that the function actually isn't called (nor emitted into assembly
etc.).
The assumption is if this function would be called and returned false at this
spot,
it would be UB.
So, VRP walks the assumption function (after optimizations are performed on it,
e.g. inlining into those and various other optimizations) backwards from the
return value starting with [1, 1] and from that derives ranges for the
arguments.

Similarly to how for functions which aren't inlined but can be e.g. cloned it
is essential to get IPA SRA and IPA CP etc. optimizations to tweak the
arguments of functions (scalarize them, remove unneeded ones, replace others),
it is needed
that we optimize the assumptions similarly.  The assumption functions should be
always static and often will have a single reference (unless inlined multiple
times / loop unrolled), so it is just fine to tweak them, just those
optimizations will need
to special case the IFN_ASSUME internal calls and treat
.ASSUME (&foo, arg1, arg2, arg3);
more like
foo (arg1, arg2, arg3);
(i.e. off by one argument and treat it as if there was a call edge from the
.ASSUME
caller to foo.

  parent reply	other threads:[~2023-07-14 12:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-13 18:49 [Bug c++/109112] New: [missed optimization] odd behaviour with [[assume(...)]] and member variables ivan.lazaric.gcc at gmail dot com
2023-03-13 18:54 ` [Bug c++/109112] " jakub at gcc dot gnu.org
2023-03-13 18:57 ` [Bug tree-optimization/109112] " pinskia at gcc dot gnu.org
2023-03-13 18:58 ` [Bug tree-optimization/109112] [[assume(...)]] is not taken into account for structs pinskia at gcc dot gnu.org
2023-03-13 18:59 ` jakub at gcc dot gnu.org
2023-07-13 15:01 ` jason at gcc dot gnu.org
2023-07-13 15:06 ` jakub at gcc dot gnu.org
2023-07-13 21:00 ` jason at gcc dot gnu.org
2023-07-14 12:48 ` jakub at gcc dot gnu.org [this message]
2024-01-21  3:00 ` [Bug ipa/109112] " pinskia at gcc dot gnu.org

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=bug-109112-4-hxaf23nF6U@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).