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
next 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).