Regalloc: optimize stack slots

[xclerc]

This pull request adds a post-processing pass to
the register allocation, whose goal is to try and
reduce the number of stack slots.

The basic idea is that, within the same register
class, it is possible to use the very same slot for
several registers if their use intervals do not
overlap.

The new pass is essentially a simplified version
of linscan; the main differences are that:

• we are interested in stack slots rather than
  registers;
• we do not distinguish the different kinds of uses
  (arg/res/live) when computing the intervals;
• we do not track potential "holes" in the intervals;
• we know that, at worst, we do not save any slots but
  there is never a reason to restart the computation.

The new pass is guarded by a new "regalloc-param",
namely STACK_SLOTS_OPTIM, to ease testing, but the
pass is expected to be cheap enough (in particular
because the number of slots is often fairly low) to
be always enabled once we are confident it is correct.
On that topic, the pass is technically part of the
register allocation and hence covered by the validator.

The effect of this pull request has been measured by
counting the total number of slots in all the functions
of the compiler distribution. When comparing to upstream:

• when the optimization is disabled, the IRC allocator
  uses 40% more slots;
• when the optimization is enabled, the IRC allocator
  uses 6% fewer slots.

[xclerc]

note: b023145 only move stack slots to
a new file and e770bde introduces the
new pass

[gretay-js]

Looks good to me.

Please rebase this PR against main (it's currently against your private branch).

Comparing this PR to #1399, looks like both PRs use the same algorithm and should have the same effect on the number of stack slots, and this PR is a postprocessing step so not limited to linscan, which is nice.

While I don't expect performance improvements in generated code at all from this optimization, I hope that this PR is enough to avoid long frames #797 in most if not all cases we have seen. I checked it for #1399 on a couple of examples and they were all below long frames threshold.

In this PR, Intervals.t and Buckets.t tables are proportional to the number of stack slots, which can be pretty big for long frames. It may also be a problem in 1399 with the free list, not sure.

[xclerc]

In this PR, Intervals.t and Buckets.t tables are proportional to the number of stack slots, which can be pretty big for long frames. It may also be a problem in 1399 with the free list, not sure.

Out of curiosity, what is the largest value you have seen?
(on the compiler distribution, I saw nothing above 400.)

[gretay-js]

In this PR, Intervals.t and Buckets.t tables are proportional to the number of stack slots, which can be pretty big for long frames. It may also be a problem in 1399 with the free list, not sure.

Out of curiosity, what is the largest value you have seen? (on the compiler distribution, I saw nothing above 400.)

I don't have the numbers any more, but after PR1339 it was still in the thousands (not sure if it was the stack size or number of slots).

[xclerc]

(not sure if it was the stack size or number of slots)

Indeed, my hunch was that what matters for the limit
is ~the number of points multiplied by the average
number of slots, and that the latter would remain low.

[mshinwell]

dune and CI only