Inline single gotos

[ncruces]

This inlines unique gotos to code that can't otherwise be reached, and that only has explicit exit points.

This is another very ambitious optimization, that further reduces the maximum nesting level of SQLite from 108 to 40 (it's at 222 at the current release).

Problems:

1. is it correct? seems to be…
2. it's really slow; and it's unclear how to make it faster

For example, translating lightningcss becomes a 40 second affair.

cc: @pgaskin @msuozzo

[ncruces]

The slowness comes from "restarting" the optimization from scratch every time a goto is inlined, until no gotos can be inlined anymore. This is slow for large functions, but is necessary because the code can move from "far away" places.

I've also tried collecting all the gotos we want to inline, then doing a pass for each goto that we want to inline, but it takes about as much time.

[pgaskin]

Will take a look on Saturday (edit: some stuff came up, won't get to it on the weekend) next week.

[ncruces]

Results for LightningCSS are similarly impressive: maximum nesting was initially 607, InlineSwitchGotos brings it down to 278, InlineSingleGotos to 121.

The cost is processing time: 10s, InlineSwitchGotos makes it 12s, but InlineSingleGotos blows it to 45s.

I could add a bound to the infinite loop, but LightningCSS needs it to be in the multiple hundred.

Notable is that both this and the switch optimization, achieve their goals without introducing code duplication: code is "moved" around, not "copied".

To improve the "slow compile" situation we need function outlining, I agree, which should help bound the runtime of this pass too.

The first line of defense there should be on the generation side: it really makes no sense that Rust/whatever creates 100Kb functions. Must be: code generation, templating, too agressive optimization. OTOH, I don't generate pretty code, so who am I to complain.

I've been slow on that front because whatever I create there should be the same thing needed to "outline" functions for the purposes of using defer in exception handling, but exception handling requires other stuff that I haven't yet done.

[ncruces]

I've managed to make the transform quite a bit faster. LightningCSS is now closer to 30s. So, InlineSingleGotos takes about as much as … everything else. But it's a lot of work: the bigger functions have over 200 goto statements to inline, and require many passes to eventually settle.

[ncruces]

I've been slow on that front because whatever I create there should be the same thing needed to "outline" functions for the purposes of using defer in exception handling, but exception handling requires other stuff that I haven't yet done.

Small step there: spec tests for it aren't supported by wabt wast2json; 7cf5bf3 adds support for wasm-tools wast2json too.

[msuozzo]

Tested on the treesitter parsers and it seems to be a no-op with the exception of one of them (golang) which sees a 20% reduction in size. No observable changes in behavior so looks good to me.

[pgaskin]

Verified 4d29a9d against:

• pgaskin/go-woff2@c329817 (no change to the generated code)
• pgaskin/go-marisa@6291617 (a few changes, mostly the same though)
• pgaskin/go-lightningcss@b10cc78 (significant improvements to size and compilation performance, even without the function outlining patch) (with GOMAXPROCS=8, 263.70user 10.95system 1:40.74elapsed 272%CPU (0avgtext+0avgdata 8411900maxresident)k)
• pgaskin/go-pcapfilter@a439802 (no change to the generated code)
• a few other things I'm working on

The optimization code looks good, and I don't see any obvious issues with it.

[pgaskin]

The Validate the optimization is a little bit vague, when I first read it, I thought it was trying to do an additional sanity check rather than a core part of the optimization.