Quoting Richard Henderson <r...@redhat.com>:
Andrew Pinski points out that the feature could probably be
equivalently implemented via outlining and function calls
(I assume well back at the gimple level).
Function calls would mean that you'd have to deal with
call-clobbered registers - any working size set savings from outlining
could easily be drowned by worsening register allocation or insertion of
caller-save instructions. And you can't easily set multiple values in
specific registers and stack slots. Unless you want to add fancy custom
ABIs for the outlined functions.
And then there is the issue that function tend to have a single
return address. You might have a complex piece of error handling code
that makes a decision where it comes back into the hot code. With a
function, you would need yet another return value, and then a tablejump
depending on that value.
At which point we
no longer have cross-segment jump_insns at the rtl level,
which seems like a Really Big Win to me at this point.
I suppose the basic problem is that these jumps are so easily mistaken for
ordinary jump_insns. If they were more obviously different, like a tablejmp,
we'd leave them alone by default. We don't do jump threading through
non-simplified tablejumps, either.
What would you think about putting the destination section in the
instruction pattern?
Of course, changing the rtl representation doesn't fix the problems with
passes like cfglayout.
These might indeed be better off with a different model for a jump into
a cold section; e.g. it could be thought of as an instruction that sets
a vector of registers and memory locations depending on another such vector,
and then does (optionally) a multi-way jump. Indeed a bit like a call
instruction, but with more potential side effects that we want, and less
that we don't want.
Not that I'm volunteering to actually do the work to implement
any such scheme.
Same here... just some thoughts.
