On 10/7/22 15:04, Qing Zhao wrote:
On Oct 7, 2022, at 2:34 AM, Richard Biener <richard.guent...@gmail.com> wrote:
On Thu, Oct 6, 2022 at 3:18 PM Qing Zhao <qing.z...@oracle.com> wrote:
On Oct 6, 2022, at 4:29 AM, Richard Biener <richard.guent...@gmail.com> wrote:
On Wed, Oct 5, 2022 at 8:18 PM Qing Zhao via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
On Oct 5, 2022, at 1:36 PM, Martin Liška <mli...@suse.cz> wrote:
On 10/5/22 16:50, Qing Zhao wrote:
I have two questions on this:
Hello.
1. What’s the motivation to enable -flive-patching with -flto? Is there any
application that will try -flive-patching with -flto now?
We're planning supporting GCC LTO Linux kernel support, so that's one
motivation. And the second one is a possible
use in user-space livepatching. Note majority of modern distros default to
-flto (openSUSE, Fedora, Debian, Ubuntu, ...).
Okay, I see. That’s reasonable.
2. Why only enable -flive-patching=inline-clone with -flto?
Because the inline-only-static level (which you added/requested) would have to
properly
block inter-procedural inlining that happens in LTO
(can_inline_edge_by_limits_p) and
I'm not sure it would be properly blocked. So, feel free to extend my patch if
you want?
-flive-patching=inline-only-static
Only enable static functions inlining, all the inlining of external visible
functions are blocked, So, LTO should be compatible with this naturally without
any issue, I think.
i.e, when "-flive-patching=inline-only-static -flto" present together, all the
inter-procedural inlining should be automatically blocked by
-flive-patching=inline-only-static already.
Do I miss anything here?
WPA will promote externally visible functions static when all accesses
are from LTO IR, I don't think we preserve
the "original" visibility for IPA inlining heuristics.
WPA is Whole Program Analysis?
Yes.
Okay, then It will promote all static function to extern functions. That’s
reasonable.
No, all extern functions to static functions.
Oh, really? Why change “extern” to “static”? (I recall that studio compiler
promote static to extern for inter-procedural inlining)
Because the linker LTO plug-in can get information about symbols are really
and the thus some of them can before static and not visible.
Is it hard to preserve the original “static” visibility in the IR?
Probably not hard, and the IPA pass adjusting visbility could as well
mark the functions
as not to be inlined with -flive-patching=inline-only-static.
Okay, then the implementation should be doable?
OTOH inline-only-static could disable WPA inlining and do all inlining early ...
Inline-only-static ONLY inlines static functions, how can it disable WPA
inlining? Don’t quite understand here.
it's a flag so it can be used to control other things.
When -flive-patching=inline-only-static is specified by the user, user
explicitly request ONLY inlining static functions.
Even when LTO is enabled, if only static function inlining is enabled, user
gets what he/she want. So I didn’t see any issue here.
Please see Honza's previous email about the second inliner.
Anyway, I'm going to install my patch that handles inline-clone option value.
Martin
Let me know if I still miss anything here>
Thanks.
Qing
thanks.
Qing
Richard,
thanks.
Qing
Martin
thanks.
