RFR: JDK-8207169: X86: Modularize cmpxchg-oop assembler for C1 and C2
Roland Westrelin
rwestrel at redhat.com
Mon Sep 3 08:41:21 UTC 2018
Hi Erik,
> The C1 basic blocks are built and optimized as part of the HIR and are
> not to be changed after that. Once the HIR is generated, the LIR inserts
> operations required for lowering this optimized HIR to machine code.
> After IR::compute_code() of the HIR, those basic blocks are set in
> stone. That means that any control flow alterations needed by the
> LIRGenerator, which comes into play after that, is going to use branches
> within the HIR basic block instead (as we promised not to change the HIR
> basic blocks after the HIR is built and optimized). I can see how that
> might feel like a hack, but that is kind of the way that things are
> currently done in C1. It is used this way for all barrier sets today
> (UseCondCardMark for card marking GCs, for G1, ZGC), and it's also used
> by T_BOOLEAN normalization, switch statements, checking for referents in
> unsafe intrinsics etc. I suppose the stubs inserted at the LIR level
> also similarly break the basic block abstraction of the HIR level. These
> are things that can of course be changed into a more strict basic block
> model even at the LIR level. But I don't know how much that would help
> given that this is just the pass before lowering to machine code. But
> that is a whole different discussion.
Adding a loop within a basic block is simply not possible. The register
allocator won't know it's a loop and has no way to know operands are
live across iterations. So it's not like we even have a choice.
Roland.
More information about the hotspot-compiler-dev
mailing list