> The idea (which I may not have conveyed sufficiently well), is that we
> eliminate rarely-used or even nonsensical constant variants of ops.
> That is, get a constant gain at the expense of a cost to rare use
> cases.
Works for me, as long as we recognize that we're going to maintain
a special-c
On Sun, May 30, 2010 at 10:51:36PM -0700, Peter Lobsinger wrote:
>>> An idea that's been batted about a bit lately is that our op-bloat is
>>> at least partly caused by all the constant-argument variant forms all
>>> of our ops need to support.
>>> ...
>
On 5/31/10 4:50 PM, Patrick R. Michaud wrote:
The above proposal looks to me as though it is reducing the number
of opcodes at the expense of increasing the runtime opcode dispatches
and the size of the resulting bytecode. That feels very much like
a false optimization to me. (Again, I may be
t forms all
>> of our ops need to support.
>> ...
>> To address this, the constant_unfolding branch adds a step to IMCC
>> instruction selection to check for non-const variants of an
>> as-of-yet-unfound op. If found, this op is used and constant arguments
>> are
On Sun, May 30, 2010 at 10:51:36PM -0700, Peter Lobsinger wrote:
> An idea that's been batted about a bit lately is that our op-bloat is
> at least partly caused by all the constant-argument variant forms all
> of our ops need to support.
> ...
> To address this, the constant_u
On 5/31/10 6:51 AM, Peter Lobsinger wrote:
To address this, the constant_unfolding branch adds a step to IMCC
instruction selection to check for non-const variants of an
as-of-yet-unfound op. If found, this op is used and constant arguments
are handled by assignments to temporary registers. This
An idea that's been batted about a bit lately is that our op-bloat is
at least partly caused by all the constant-argument variant forms all
of our ops need to support.
To address this, the constant_unfolding branch adds a step to IMCC
instruction selection to check for non-const variants of
