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.
Use the inferred type variables to construct a type argument for builder
methods. This is for those instructions where the result types cannot be
computed from the result types.
Add an assertion for the value placements that we don't support yet.
1. A primary result in the source pattern becomes a secondary result in
the destination.
2. A secondary result becomes a secondary result, and the destination
instruction is not exactly matching the source.
Since we're deconstructing an instruction anyway, go ahead and resolve
any value aliases on its arguments before we construct the replacement
instructions.
If a secondary value in the source pattern becomes a primary value in
the destination pattern, it is not possible to overwrite the definition
of the source value.
Instead, change the original source value to an alias to the new promary
value.
When expanding iadd_cout, the original instruction is replaced with an
iadd, and an icmp is inserted after the iadd.
Make sure we advance the insertion position after replacing iadd_cout so
the icmp gets inserted *after* iadd.
When an illegal instruction is replaced with other instructions, back up
and revisit the expanded instructions. The new instructions need to have
encodings assigned too.
This also allows for expansions to contain illegal instructions that
need to be legalized themselves.
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.
There's 4 classes of variables, depending on whether they have defs in
the source and destination patterns.
Add more XForm verification: In a legalize XForm, all source defs must
be outputs.
Fix a legalize pattern bug caught by this.
This is a work in progress. The 'legalizer.rs' file generated by
gen_legalizer.py is not used for anything yet.
Add PEP 484 type annotations to a bunch of Python code.
