At 3:24 PM +1000 4/18/02, Andrew J Bromage wrote:
>G'day all.
>
>This patch introduces a new op parameter type "inconst", which is like
>"in" except that it only produces const versions of the op (i.e. it
>will not take values from registers).
>
>This is mostly for the benefit of branch targets. The "feature" of
>using register values as branch targets can safely be eliminated
>because:
>
> - Nobody uses it.
> - Nobody is likely to use it any time soon.
> - In the rare event that you may want to use it, you could
> always branch to a jump_i op.
> - None of the JIT ports implement it. This will save work.
> - It is in general impossible for an optimizer to determine
> where the branch targets are if you allow registers as
> branch targets. Even when it's possible, it's too hard.
> - Eliminating it speeds up life.pasm by about 5-10% according
> to my highly unscientific benchmark.
>
>There's probably an argument for implementing "inreg" as well, for
>the benefit of jump and jsr. Is "inreg" a good name?
I've applied this, with the exception of the branch and bsr ops. At
the moment, I agree--I can't see any case where "if" or "gte" needs
to have a variable target. (I can see it for branch, bsr, jump, and
jsr, as those are partially for subroutine dispatch, so no changes
there)
I'm surprised at the speedup--that seems rather odd, and just shrunk
filesize doesn't seem to be right. But I suppose we get a denser
executable. (At some point we need to reorganize things to take
advantage of L2 and L3 cache coherency issues, but not today)
Anyway, worse case they really really need to go back in, and we can
put them back.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
