JIT: defer creating throw helper blocks until simple lower

[AndyAyersMS]

Defer creating throw helper blocks until just before the late flow graph optimizations. This removes some of the flow graph updates from morph, with the aim of making it easier to show that an RPO traversal in morph is safe.

Unfortunately, it's hard to get these blocks in the exact same places they were before, so there are quite a few diffs. They are generally improvements. I also saw some cases where the early creation of throw helpers in try regions inhibited loop recognition; this no longer happens, and may enable loop cloning (and hence size increses).

Diffs

This also lays the groundwork for removing simple lowering.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Don't create any throw helper blocks until simple lowering. This removes some of the flow graph updates from morph, with the aim of making it easier to show that an RPO traversal in morph is safe.

Unfortunately it's hard to get these blocks in the exact same places they were before, so there are some diffs.

Author:	AndyAyersMS
Assignees:	AndyAyersMS
Labels:	area-CodeGen-coreclr
Milestone:	-

[AndyAyersMS]

cc @dotnet/jit-contrib

Code size improvements here are somewhat surprising.... highlighting the need for a global layout algorithm, as there are multiple considerations to determine optimal placements of blocks.

[AndyAyersMS]

SPMI replay errors look like #93527

[EgorBo]

Nice wins! I presume it should fix various cases where we have unreachable throw helper blocks, e,g. I've just came up with:

voidTest(boolcond){intb=10;if(cond){_=checked((byte)b);}}

Emits:

G_M12030_IG01: ;; offset=0x0000subrsp,40 ;; size=4 bbWeight=1 PerfScore 0.25G_M12030_IG02: ;; offset=0x0004addrsp,40ret ;; size=5 bbWeight=1 PerfScore 1.25G_M12030_IG03: ;; offset=0x0009call CORINFO_HELP_OVERFLOWint3 ;; size=6 bbWeight=0 PerfScore 0.00; Total bytes of code 15

[AndyAyersMS]

presume it should fix various cases where we have unreachable throw helper blocks

Actually, no... let me look into this as a follow-up.

[AndyAyersMS]

presume it should fix various cases where we have unreachable throw helper blocks

Actually, no... let me look into this as a follow-up.

Unfortunately, this seems tricky. We don't know if we really need a throw helper until after codegen, and by then it's not so easy to get rid of things. I suppose I can at least see how often a helper ends up being unused, if it turns out this is a common thing, we can find a way to fix it.

[jakobbotsch]

It looks like this PR had a ton of misses, so the diffs may be even greater (depending on the reason for the misses I suppose).

[AndyAyersMS]

It looks like this PR had a ton of misses, so the diffs may be even greater (depending on the reason for the misses I suppose).

It could be a bad sign, like the JIT is asking for throw helpers now that it didn't ask for before. Maybe once we have new collections we can do a trial revert and see how that looks.

[AndyAyersMS]

PMI diffs show some new unnecessary throw helper blocks, eg

So let me dig into this and see how we can avoid adding such things.