It could be useful to not only allow IR verification at one specific point after compiling the @Test method but actually do it in multiple stages, for example if we deopt in between and then expect a different IR:

@Test
// Do matching on the first compilation
@IR-stage-1(counts = {IRNode.STORE_I, "1"})
// Do matching on the second compilation
@IR-stage-2(counts = {IRNode.STORE_I, "2"})
void test(boolean flag) {
    if (flag) {
         iFld = 34;
    } else {
         iFld2 = 23;
    }
}

@Run(test = "test")
void run() {
    if (/* at warmup */) {
        test(true); // We never take the else branch in test() and insert a trap
    } else {
        // Warm-up over, compiled by IR framework
        test(false); // Hit trap and we deopt.
        for (int i = 0; i < 10000; i++) {
            // We make sure both branches are taken
            // At some point, we recompile and get an IR without traps
            test(i % 2 == 0 ? true : false);
        }
        // Side node: With multiple stages, we might need something more powerful than just a
                             boolean warm-up passed with the RunInfo object. Maybe we can have a
                             stage counter instead where "stage 0 == warm-up" or something like that.
    }
}

The challenge here is not only to be able to pick up multiple compilations to do IR matching on but also find those that the IR test is actually interested in. A user could very well define a @Run method that does some complicated things during warm-up that does cause compilation, deoptimization and recompilation again. We need a way to still filter those out and only pick the interesting ones.

One easy solution could be to just pick the last N one if we have N stages defined for IR matching. However, we need to be careful when the user provided logic to trigger recompilations is off by mistake but somehow there are other, uninteresting compilations which are then picked up and somehow makes his IR matching pass.

This suggests that it would be good to come up with a mapping mechanism. Maybe we can establish some kind of markers for a @Test method that signals the beginning of "stage X". We run with -Xbatch, so there should be no race with concurrently executing and compiling methods.

This was suggested by [~roland] (feel free to expand the description).