This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: LTO inliner -- sensitivity to increasing register pressure
- From: Xinliang David Li <davidxl at google dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Aaron Sawdey <acsawdey at linux dot vnet dot ibm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Martin Jambor <mjambor at suse dot cz>
- Date: Fri, 18 Apr 2014 13:34:05 -0700
- Subject: Re: LTO inliner -- sensitivity to increasing register pressure
- Authentication-results: sourceware.org; auth=none
- References: <53515624 dot 5060509 at linux dot vnet dot ibm dot com> <CAAkRFZJ4S+tT2+DtYzptvyb8BOOAatFj-dJzABd8UiVtn2KUug at mail dot gmail dot com> <1397847967 dot 19063 dot 10 dot camel at ragesh3 dot rchland dot ibm dot com> <20140418195153 dot GE10795 at kam dot mff dot cuni dot cz>
On Fri, Apr 18, 2014 at 12:51 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> What I've observed on power is that LTO alone reduces performance and
>> LTO+FDO is not significantly different than FDO alone.
>>
>> I agree that an exact estimate of the register pressure would be a
>> difficult problem. I'm hoping that something that approximates potential
>> register pressure downstream will be sufficient to help inlining
>> decisions.
>
> One (ortoghonal) way to deal with this problem would be also to disable
> inlining of functions called once when the edge frequency is low.
> I.e. adding to check_callers something like
> edge->frequency > CGRAPH_FREQ_BASE / 2
> if you want to disqualify all calls that have only 50% chance that they
> will be called during function invocation.
>
> Does something like that help in your cases?
>
> It would help in the case Linus complained about
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49194
>
> The difficulty here is that disabling inlies on not so important paths
> may prevent SRA and other optimizations so it may in turn also penalize
> the hot path. I saw this in some cases where EH cleanup code was optimized
> for size.
yes. The callsite may be cold, but the profile scaled callee body may
still be hot. Inlining the callee allows more context to be passed.
Similarly for hot callers, cold callees may also expose more
information (e.g, better alias info) to the caller.
David
>
> Perhaps SRA canalso be extended to handle cases where non-SRAable code is
> on a cold path?
>
> Honza