|
From: Jeremy F. <je...@go...> - 2002-12-09 21:51:40
|
On Mon, 2002-12-09 at 11:32, Julian Seward wrote:
> [...]
> > That said, it has been a long while since I looked at that patch in
> > detail, so maybe there's some simple improvements. In particular, I
> > think it leaves some dead code, so that should be cleaned up.
>
> I just a bit disinclined against having two mechanisms for integer
> multiplication (the helper fns _and_ direct ucode). If the direct route
> covered all the bases, I'd take it. Not only does it allow scope for better
> instrumentation, the generated code is surely better too.
Well, there are really two kinds of multiply: the NxN->2N set, and the
NxN->N set. The latter has a UInstr, but the former are done with
helpers. Since the 2N forms are slower instructions which stomp
specific registers, they're not really desireable to generate all the
time; it seems to me that to support inline code generation for the 2N
forms pretty much requires separate opcodes, which leads for 4 being
used for multiply (though perhaps a flag can be used to distinguish
either N from 2N or signed from unsigned, though all the unsigned
multiplies are 2N).
I don't think the quality of the generated code is all that important
since the helpers aren't that expensive to call (push and pop are
cheap), and 2N forms are hardly ever used in code I've tested. Also,
making sure that everything is in the right register would kill a lot of
the potential efficency gains (unless the regalloc can be changed to
make sure that specific temp end up in specific registers so that the
rearrangement happens at compile time rather than runtime - but that
sounds even more complex).
J
|