RFR: 8308869: C2: use profile data in subtype checks when profile has more than one class [v6]

[Vladimir Ivanov]

On Wed, 21 Jun 2023 07:02:35 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Late expansion allows some optimizations to trigger that wouldn't otherwise. 

I agree that early expansion may hinder optimizations for polymorphic case.
But bimorphic case may enrich the receiver with more precise type information. 

> Carrying the JVM state in the SubTypeCheck looks like too much extra complexity to me.

Yes, I agree.

> It felt easier in terms of memory management. If we have some extra data embedded in the SubTypeCheck node, is it a pointer or the full data structure?

`ciCallProfile` has fixed size and is passed by value. Embedding the whole structure inside `SubTypeCheck` doesn't look problematic. It refers to CI entities which should be kept alive for the duration of the compilation.  

> One thing to consider is that we don't necessarily want to common 2 SubTypeCheck nodes with the same object/super kass inputs. 

I thought about commoning of SubTypeCheck nodes as well and there are other cases when it may be undesireable. For example, when 2 checks are performed in 2 subbranches with low frequencies, we don't want to place commoned check in a hot dominating block. 

I'd prefer to see `SubTypeCheck` to have control input which is explicitly relaxed to accommodate commoning.


Overall, I'm fine with late expansion of profile-guided type checks for now, but embedding profile data info SubTypeCheck should significantly simplify the patch without compromising the benefits. Also, enhancing profiling support separately may be a viable tradeoff as well. Inaccuracies in code shape classification don't look like a critical issue when the guards are introduced during macro expansion. 

We can explore other optimization opportunities later (e.g., profile for superclasses may help reflection case).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14375#issuecomment-1603092517