public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Jambor <mjambor@suse.cz>
To: Erick Ochoa <eochoa@gcc.gnu.org>, gcc@gcc.gnu.org
Subject: Re: Question about speculative make_edge_direct_to_target during LTO/IPA_PASS
Date: Fri, 01 Jul 2022 14:48:27 +0200	[thread overview]
Message-ID: <ri6y1xdhuck.fsf@suse.cz> (raw)
In-Reply-To: <CAJ_nqzg6t1Qt58rWn7P6YS1GPb5FtyeVO51cJK4jcm2izAZU6A@mail.gmail.com>

Hi,

On Fri, Jul 01 2022, Erick Ochoa via Gcc wrote:
> Hi,
>
> I have a pass that is able to speculate the target of indirect function
> calls. This pass is an IPA_PASS. It:
>
> 1. generates summaries with the possible targets.
> 2. writes analysis summary
> 3. reads analysis summary
> 4. combines the results from multiple partitions and if needed fixes the
> targets
> 5. writes opt summary
> 6. reads opt summary
> 7. calls ipa_make_edge_direct_to_target with speculative=true

Why so late, why not as part of number 4?

>
> This pass is successful in that I can observe the transformation in the
> generated gimple. (A function test and a direct function call in one branch
> and the indirect function call in the other.)  However, I would like to
> make the edges in the call graph visible to other IPA passes, particularly
> ipa-cp.

As long as you schedule your pass before IPA-CP and create speculative
edges before its WPA, that should then just work.  I mean, IPA-CP may be
too conservative and its heuristics may need to be tweaked, but it
should see the speculative edges and propagate through them just fine.
Is that not so?

> For this, I would need to create virtual clones during the WPA
> stage.

I do not understand what the virtual clones would represent.  How should
they be different from the original when materialized?

> I am a little unfamiliar with virtual clones. What kind of
> information would I need to store in the analysis summary and is there a
> way to create speculative virtual clones? Can someone point to a similar
> piece of code in GCC where this happens?

Well, IPA-CP creates virtual clones.  Information associated with it
represents the special context for which they are created (see
create_specialized_node in ipa-cp.cc) but I am not sure what that would
be in your case.

I am also not sure what you mean by speculative virtual clones, if
virtual clones with only speculative edges leading to them, than those
can exist and (unless the call is considered cold), they are not removed
as uninteresting (see code in speculation_useful_p).

But I really think that making the edges speculative early is likely to
fix your issues.

Martin

  reply	other threads:[~2022-07-01 12:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-01  9:46 Erick Ochoa
2022-07-01 12:48 ` Martin Jambor [this message]
2022-07-07 13:20   ` Erick Ochoa
2022-07-08 15:31     ` Martin Jambor
2022-07-14 12:40       ` Erick Ochoa

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=ri6y1xdhuck.fsf@suse.cz \
    --to=mjambor@suse.cz \
    --cc=eochoa@gcc.gnu.org \
    --cc=gcc@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).