public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: hubicka@ucw.cz, gcc@gcc.gnu.org
Subject: ipa-inline & what TARGET_CAN_INLINE_P can assume
Date: Mon, 25 Sep 2023 18:14:20 +0100	[thread overview]
Message-ID: <mpto7hqyy37.fsf@arm.com> (raw)

Hi,

I have a couple of questions about what TARGET_CAN_INLINE_P is
alllowed to assume when called from ipa-inline.  (Callers from the
front-end don't matter for the moment.)

I'm working on an extension where a function F1 without attribute A
can't be inlined into a function F2 with attribute A.  That part is
easy and standard.

But it's expected that many functions won't have attribute A,
even if they could.  So we'd like to detect automatically whether
F1's implementation is compatible with attribute A.  This is something
we can do by scanning the gimple code.

However, even if we detect that F1's code is compatible with attribute A,
we don't want to add attribute A to F1 itself because (a) it would change
F1's ABI and (b) it would restrict the optimisation of any non-inlined
copy of F1.  So this is a test for inlining only.

TARGET_CAN_INLINE_P (F2, F1) can check whether F1's current code
is compatible with attribute A.  But:

(a) Is it safe to assume (going forward) that F1 won't change before
    it is inlined into F2?  Specifically, is it safe to assume that
    nothing will be inlined into F1 between the call to TARGET_CAN_INLINE_P
    and the inlining of F1 into F2?

(b) For compile-time reasons, I'd like to cache the result in
    machine_function.  The cache would be a three-state:

    - not tested
    - compatible with A
    - incompatible with A

    The cache would be reset to "not tested" whenever TARGET_CAN_INLINE_P
    is called with F1 as the *caller* rather than the callee.  The idea
    is to handle cases where something is inlined into F1 after F1 has
    been inlined into F2.  (This would include calls from the main
    inlining pass, after the early pass has finished.)

    Is resetting the cache in this way sufficient?  Or should we have a
    new interface for this?

Sorry for the long question :)  I have something that seems to work,
but I'm not sure whether it's misusing the interface.

Thanks,
Richard

             reply	other threads:[~2023-09-25 17:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-25 17:14 Richard Sandiford [this message]
2023-09-25 17:26 ` Andrew Pinski
2023-09-25 17:46   ` Richard Sandiford

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=mpto7hqyy37.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=gcc@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    /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).