As discussed in #3.
Once we know the controlling type variable of a polymorphic instruction,
the types of input operands are either bound to known types, or they can
vary freely.
The call arguments on call_indirect should not include the fixed callee
argument.
Add legalizer assertions to verify that signatures are actually valid
after legalization. If not, we would get infinite legalizer loops.
Like the entry block arguments, the return values from a call
instruction need to be converted back from their ABI representation.
Add tests of call instruction legalization.
These low-level functions allow us to build up a list of instruction
results incrementally. They are equivalent to the existing
attach_ebb_arg and append_ebb_arg.
- abi.cton is for testing the actual RISC-V ABI.
- legalize-abi.cton is for testing the legalizer around ABI boundaries.
- parse-encoding.cton is for testing the parser's handling of RISC-V
encoding and register annotations.
Instead, just return the first of the detached values, and provide a
next_secondary_result() method for traversing the list.
This is equivalent to how detach_ebb_args() works, and it allows the
data flow graph to be modified while traversing the list of results.
The type signatures of functions can change when they are legalized for
a specific ABI. This means that all call and return instructions need to
be rewritten to use the correct arguments.
- Fix arguments to call instructions.
- Fix arguments to return instructions.
TBD:
- Fix return values from call instructions.
When the CRETONNE_DBG environment variable is set, send debug messages
to a file named cretonne.dbg.*.
The trace facility is only enabled when debug assertions are on.
Now that some instruction formats put all of their value arguments in a
value list, we need to know how many value are fixed and how many are
variable_args.
CC @angusholder who may need this information in the verifier.
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.
Allow some flexibility in the signature matching for instruction
formats. In particular, look for a value list format as a second chance
option.
The Return, ReturnReg, and TernaryOverflow formats all fit the single
MultiAry catch-all format for instructions without immediate operands.
No instruction sets actually have single instructions for materializing
vector constants. You always need to use a constant pool.
Cretonne doesn't have constant pools yet, but it will in the future, and
that is how vector constants should be represented.
Instruction formats are now identified by a signature that doesn't
include the ordering of value operands relative to immediate operands.
This means that the BinaryRev instruction format becomes redundant, so
delete it. The isub_imm instruction was the only one using that format.
Rename it to irsub_imm to make it clear what it does now that it is
printed as 'irsub_imm v2, 45'.
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.
These two tuples contain operand indexes of the explicit value operands
and immediate operands respectively. We can no longer use the
instruction format value_operands field.
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.
With the Return and ReturnReg formats converted to using value lists for
storing their arguments, thee are no remaining instruction formats with
variable argument lists in boxed storage.
The Return and ReturnReg formats are also going to be merged since
they are identical now.
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.
