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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
