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.
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.
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.
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.
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.
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'.
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.
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.
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.
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.
