constant_unfolding branch

Patrick R. Michaud pmichaud at
Tue Jun 1 15:43:49 UTC 2010

> 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-case list of ops.  (We special-case an awful lot in Parrot,
so I don't see this as going against the grain.)

> Have I mentioned how easy and now opsc make suppressing the
> generation of const variant ops? It is as simple as chaning "in INT"
> to "invar INT" in the op declaration. I only changed four lines. The
> hundreds of line changes in the patch are all generated bootstrap
> files.

This is excellent.

> >> beyond the *cclass variants, and (2) doing this feels like it makes the
> >> opcode set less regular instead of more regular (which was my original
> >> motivation for suggesting opcode reductions).
> Yes, leaving only the common constant forms is exactly the intent.
> (1) having the local pessimisation available costs almost nothing. It
> is ~50 lines of code, on a branch only taken when you've failed to
> find an op anyways, and took me less time to write than this email. It
> allows tuning if we choose to use it.
> (2) which opcode set do you want regular? the one visible to
> PIR/PASM/PCT or the one in PBC? The PIR opset doesn't change at all
> with this. 

Part of what makes PCT/PAST so challenging is that it has to deal with
a highly irregular opcode set and syntax.  PCT basically has to maintain
a table of opcodes it knows and cares about and make sure that high-level
operands are correctly boxed/unboxed into operands the opcodes will accept.

> >> It may also be worth noting that PCT currently attempts to bias towards
> >> the constant-form of opcodes wherever it can, under the theory that this
> >> leads to faster/smaller code. [...] 
> PCT is a major Parrot user, and will likely be a factor in what ops
> are considered underused.
> Would you care to elaborate (either here or elsewhere) about how PCT
> biases towards using constants? Aren't they more or less simply
> properties of the code being compiled?

Not always.  As mentioned above, what the HLL considers a constant
may in fact have to be mapped to a register (and sometimes boxed as
a PMC) in PIR in order to be a compatible operand with the desired
operation, because not all combinations are available in the opcode set.  
(Many of the PMC comparison and string opcodes are particularly 
difficult to deal with here.) But we don't want to always simply map 
all HLL constants to registers or PMCs; when possible we'd like to 
take advantage of any (more efficient (?)) opcodes that can use the 
constant arguments directly.

So, PAST::Compiler's internal opcode table knows which opcodes accept
which types of operands (at least for some commonly used opcodes), and
PAST generally tries to minimize the number of conversions needed to
map from the values the children nodes produce to the inputs the operator
node requires.  So when PAST knows that a given opcode can accept
a constant operand, it avoids any extra boxing/unboxing steps that might
otherwise be required.


More information about the parrot-dev mailing list