public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Erick Ochoa <eochoa@gcc.gnu.org>
To: "Martin Liška" <mliska@suse.cz>
Cc: Richard Biener <richard.guenther@gmail.com>,
	GCC Development <gcc@gcc.gnu.org>
Subject: Re: Creating a wrapper around a function at compile time
Date: Fri, 15 Jul 2022 10:33:08 +0200	[thread overview]
Message-ID: <CAJ_nqzhL7n6-GupHx5K=M+t4VSGdE+Q8yJLOUtxQ_Sv5KGbupA@mail.gmail.com> (raw)
In-Reply-To: <0d025b0a-0094-6457-0073-2bd7ccf51c80@suse.cz>

Awesome! Thanks!

Let's go a little bit into the transformation mechanics itself. I am
somewhat familiar with LTO but I am always confused about the
transformations scheduled during WPA.

Let's assume that:

1. we have the profiling pass, which profiles each argument in each
callsite.
2. we are now running in the -fprofile-use so that means that we have
access to the value profiles for each of the arguments
3. there's an IPA/LTO pass which creates edge summaries storing "likely"
values for each of callsite/argument
4. we have a heuristic that let's us decide to some extent which subset of
likely values will yield good results (heavily used and specialization is
greatly beneficial if found) and run it during WPA.

Then, what happens next? I know that the idea is to create some parameter
tests at the callsite and call the respective parameter. The gap in my
understanding is that at this point I am assuming we are in WPA and
therefore have no function bodies to add these parameter tests. Would it be
sufficient to do the following:

1. Store in optimization (edge) summaries the (argument position x value x
specialized function version)
2. During LTRANS actually perform the transformation for the parameter test

Or is there some other way? I am still working on understanding how
ipa_make_edge_direct_to_target with speculative = true adds the edge and
function test during WPA. Otherwise, if we go with the two steps above, the
edges won't be visible to the rest of the IPA optimizations.

I'll be reading the cgraph_edge::make_speculative and the rest of the
infrastructure a bit more closely...

Any help or direction is greatly appreciated. Thanks!

-Erick

      reply	other threads:[~2022-07-15  8:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-14 12:38 Erick Ochoa
2022-07-14 13:27 ` Richard Biener
2022-07-14 13:29   ` Richard Biener
2022-07-14 13:46     ` Erick Ochoa
2022-07-14 13:50       ` Richard Biener
2022-07-14 14:08         ` Erick Ochoa
2022-07-14 14:10           ` Martin Liška
2022-07-14 14:25             ` Erick Ochoa
2022-07-15  8:10               ` Martin Liška
2022-07-15  8:33                 ` Erick Ochoa [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='CAJ_nqzhL7n6-GupHx5K=M+t4VSGdE+Q8yJLOUtxQ_Sv5KGbupA@mail.gmail.com' \
    --to=eochoa@gcc.gnu.org \
    --cc=gcc@gcc.gnu.org \
    --cc=mliska@suse.cz \
    --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).