This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Cost model for indirect call speculation
- From: Andi Kleen <andi at firstfloor dot org>
- To: Xinliang David Li <davidxl at google dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Martin LiÅka <marxin dot liska at gmail dot com>
- Date: Mon, 12 Aug 2013 09:00:07 -0700
- Subject: Re: Cost model for indirect call speculation
- References: <20130811231123 dot GB9197 at kam dot mff dot cuni dot cz> <CAAkRFZK2HAoitKDB=D9AkHifSfdVrQ+v59b9wYP+GS98S-GnGw at mail dot gmail dot com>
Xinliang David Li <davidxl@google.com> writes:
> I like the approach in general -- in the past, indirect call promotion
> and function inlining heuristics are disconnected -- which can lead to
> either missing promotions or useless ones. This approach solves the
> problem.
>
> On Sun, Aug 11, 2013 at 4:11 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> Hi,
>> this patch adds simple cost model into indirect call speculation. First we do not
>> turn calls into speculative calls when it seems bad idea (i.e. call is cold)
>> and during inlining we remove speculations that do not seem benefical.
>> On modern chip speculative call sequence without inlining is not really going
>> to fare better than indirect call because of indirect call predictor.
>> So we keep them only if the call was inlined or if the callee is turned to clone
>> or CONST/PURE flags are propagated to them.
>>
>> We may want to add target hook specifying if target support indirect call predictor,
>> but I am not sure how important this is in practice.
>
> It might be also useful to introduce a parameter to control the
> behavior so that people can do better experiment. The capability of
> indirect branch predictions varies a lot depending on the target.
With autofdo I guess it would be best to sample for branch
mispredictions using the PMU and use that as guideline.
The branch can be always looked up in the LBR
(e.g. On Intel using BR_MISP_RETIRED.ALL_BRANCHES_PS or using
BR_MISP_EXEC.TAKEN_INDIRECT_JUMP_NON_CALL_RET [unfortunately speculative
and non precise] or on Atom BR_MISSP_TYPE_RETIRED.IND/IND_CALL)
This will always give you the best information.
-Andi
--
ak@linux.intel.com -- Speaking for myself only