Inlining heuristic trouble

[Christian Thalinger]

On Jun 21, 2011, at 3:28 AM, John Rose wrote:
> On Jun 20, 2011, at 12:17 PM, Tom Rodriguez wrote:
> 
>> On Jun 18, 2011, at 5:15 AM, Rémi Forax wrote:
>> 
>>> On 06/18/2011 03:15 AM, Tom Rodriguez wrote:
>>>> On Jun 17, 2011, at 5:00 PM, John Rose wrote:
>>>> 
>>>>> On Jun 17, 2011, at 10:21 AM, Tom Rodriguez wrote:
>>>>> 
>>>>>>> Sorry, I was thinking recording which branch of the GWT is taken and
>>>>>>> storing them in the GWT.
>>>>>>> Two GWTs should not share the same metadata.
>>>>>> This is the major problem with GWT/selectAlternative.  Previously when GWT was bytecodes we at least had a chance to get some profile information on which way the branch was likely to go but with the ricochet frame version we have no knowledge so each side of the if has equal probability.  The were no guarantees that the GWT would always be used as a fast/slow idiom but in practice it was so we used to get good data.  We'll have to find someway to capture profiles for this if we can to treat fast/slow in a more aggressive way.
>>>>> selectAlternative has a branch profile.  As long as GWT is being used as expected (for fast/slow splits), selectAlternative will have a fast/slow profile, just like the original GWT invokers.
>>>>> 
>>>>> The PROB_FAIR in CallGenerator::for_method_handle_inline could be made "smarter", by feeding from the control inputs of the Phi; that would be a good start.
>>>> Well duh on me.  When I wrote that my brain was thinking cmove instruction, not a real If diamond with probability.  I don't think fixing this will improve the inlining in the fast case but it should reduce useless inlining in the slow path.  I've got part of this working.
>>>> 
>>>> tom
>>> 
>>> But all GWT share the same selectAlternative, so the probability
>>> of the inputs of the Phi is the propability of all GWTs.
>>> I think it's better to artificially mark the fallback as never been 
>>> called instead of relying
>>> on a global shared profile.
> 
> 
> One way to do this on the cheap is to intrinsify selectAlternative in MHW, so that MHW-compiled GWT graphs automatically get fresh profilable copies of the if/then/else.  This doesn't scale to other kinds of MH graphs, of course, but GWT is arguably a fundamental building block that deserves special case to be rendered as if/then/else bytecodes.


I'm not sure I understand how that would help.  When MHW compiles a MH chain we are compiling with C2 and we don't do profiling with C2 generated code, AFAIK.  Or did you mean something else?

-- Christian