Hello all,
In order to add support for patching jump tables with fixup code [1] in
the linear register allocator, I'd like to defer creating jump tables
until after register allocation has occurred. This creation usually occurs
during the instruction selection phase, so I will need to modify the API
across all architectures to defer creating instruction selection to
another function. This is a head-up for anyone who may care about
these APIs (if you have a better idea, please let me know!) and it also
means that I'll need a little help testing my patches on the relevant
architectures:
PPC: BCTR
SPARC: JMP_TBL
X86: JMP_TBL
Cheers,
Edward
P.S. Alpha seems pretty dead. Can we punt it?
[1] Digest of the problem: the linear register allocator is a very stupid
allocator, and in particular doesn't know enough to try to make sure
that control paths that join back together have consistent register allocations.
As a result, when it notices a second jump to a block is inconsistent, it
attempts to patch up the jump with some fixup code for the registers.
The problem is that, under our current scheme, there's not an easy way
to patch up jump tables: you'd need to find the jump table and fix up
the relevant entry, and if you did that, you might break an invariant that
only one jmp_tbl instruction jumps to a jump table. Simon Marlow and I
discussed this, and we decided that the best way to fix this is to defer
creation of jump tables until after we've finished register allocation:
a jump table is carried along the JMP_TBL instruction, the allocator
can fix those instructions up, and then we emit the data sections.
I've added a test for this named jmp_tbl. Right now it fails with
some optimizations from the new code generator, on x84-64. I'd like to
see if this test-case tickles this infelicity for other archs as it
stands: it's very sensitive to the number of registers available and
I don't have an example that causes problems for x86-32.
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
