Any code that needs to manipulate a variable argument list on an
instruction will need to remove the instruction's value list first,
change the list, and then put it back on the instruction. This is
required to avoid fighting the borrow checker over mutable locks on the
DataFlowGraph and its value list pool.
Add a generated InstructionData::take_value_list() method which lifts
out and existing value list and returns it, levaing an empty list in its
place, like Option::take() does it.
Add a generated InstructionData::put_value_list() which puts it back,
verifying that no existing value list is overwritten.
The value_list flag can be inferred from the presence of VARIABLE_ARGS
in the operand list.
The boxed_storage flag is obsolete. We don't need boxed storage anywhere
no that we have value lists instead.
An instruction format is now seen as having two separate operand lists:
immediates and values. Change InstructionFormat.typevar_operand to be a
pure index into the value list.
The per-instruction format low-level constructors in InstBuilder should
be independent of the relative ordering of value and immediate operands
in order to prepare for the future instruction format merger.
Reorder their arguments such that all the immediate operands are placed
before the value operands.
For instruction formats that use a value list representation, just take
a single ValueList argument. The value lists are created by the
individual instruction constructors. This means that the format
constructor doesn't care how many of the instructions operands are
'fixed' and how many are 'variable' arguments.
Now that variable arguments are always stored in a value list with the
fixed arguments, we no longer need the arcane [&[Value]; 2] return type.
Arguments are always stored contiguously, so just return a &[Value]
slice.
Also remove the each_arg() methods which were just trying to make it
easier to work with the old slice pair.
Make some changes that will make it easier to get rid of the
'value_operands' and 'members' fields in the Python InstructionFormat
class. This is necessary to be able to combine instruction formats that
all use a value list representation, but with different fixed value
operands. The goal is to eventually identify formats by a new signature:
(multiple_results, imm_kinds, num_value_operands)
Start by adding new fields:
- imm_members and imm_kinds are lists describing the format operands,
excluding any values and variable_args operands.
- num_value_operands is the number of fixed value operands, or None in a
has_value-list format.
Use these new members in preference to the old ones where possible.
The Branch format also stores its fixed argument in the value list. This
requires the value pool to be passed to a few more functions.
Note that this actually makes the Branch and Jump variants of
InstructionData identical. The instruction format hashing does not yet
understand that all value operands are stored in the value list. We'll
fix that in a later patch.
Also convert IndirectCall, noting that Call and IndirectCall remain
separate instruction formats because they have different immediate
fields.
Add a new kind of instruction format that keeps all of its value
arguments in a value list. These value lists are all allocated out of
the dfg.value_lists memory pool.
Instruction formats with the value_list property set store *all* of
their value arguments in a single value list. There is no distinction
between fixed arguments and variable arguments.
Change the Call instruction format to use the value list representation
for its arguments.
This change is only the beginning. The intent is to eliminate the
boxed_storage instruction formats completely. Value lists use less
memory, and when the transition is complete, InstructionData will have a
trivial Drop implementation.
The List and Dict types are no longer implicitly available. They must be
imported from typing.
Type annotations must appear before the doc comment in a function. Also
fix type errors in these functions that weren't detected before.
Some polymorphic instructions don't return the controlling type
variable, so it has to be computed from the designated operand instead.
- Add a requires_typevar_operand() method to the operand constraints
which indicates that.
- Add a ctrl_typevar(dfg) method to InstructionData which computes the
controlling type variable correctly, and returns VOID for monomorphic
instructions.
- Use ctrl_typevar(dfg) to drive the level-1 encoding table lookups.
- Remove NO_VALUE and ExpandedValue::None.
- Remove the Default implelmentation for Value.
- InstructionData::second_result() returns an Option<Value>.
- InstructionData::second_result() returns a reference to the packed
option.
for InstructionData. Use generated `is_terminator()` for `Opcode`
instead. `is_terminator`, `can_trap` and `is_branch` functions are now
public.
fix syntax error
A few operands have a fixed type assigned. Create a singleton type
variable for these exceptions. Most instructions are polymorphic, so
this is a little overhead.
Eliminate the Operand.typ field and replace it with an Operand.typevar
field which is always a TypeVar, but which only exists in VALUE
operands.
We want to separate the Python classes that make up the DSL used to
define the Cretonne language from the concrete definitions.
- cdsl.types defines the ValueType class hierarchy.
- base.types defines the concrete types.
Provide a generic way of accessing the value arguments on an
instruction. This is provided as two slice references. One for the fixed
arguments and one for any VariableArgs.
The arguments() methods return an array of two slices which is a bit
awkward. Also provide an each_arg() method which passes each argument
value to a closure.
Begin emitting legalization patterns in the form of two functions,
'expand' and 'narrow' that are included in legalizer.rs.
The generated code compiles, but it is not fully working yet. We need to
deal with the special cases of instructions producing multiple results.
Polymorphic single-result instructions don't always return the
controlling type variable as their first result. They may use a derived
type variable, as for example icmp does.
All the InstrBuilder methods now consume the builder, and the non-leaf
methods return the dfg mutable reference they were holding.
This makes it possible to construct instruction builders that are only
safe to use once because they are doing more advanced value rewriting.
All of the instruction format an opcode methods are emitted as an
InstBuilder trait instead of adding them to the Bulder struct directly.
The methods only make use of the InstBuilderBase methods to create new
instructions.
This makes it possible to reuse the InstBuilder trait for different ways
of inserting instructions.
The 'lib/cretonne' directory will be the new root of a stand-alone
cretonne crate containg both Python and Rust sources.
This is in preparation for publishing crates on crates.io.
