These two value types represent the state of CPU flags after an integer
comparison and a floating point comparison respectively.
Instructions using these types TBD.
The value types are now classified into three groups:
1. Lane types are scalar types that can also be used to form vectors.
2. Vector types 2-256 copies of a lane type.
3. Special types. This is where the CPU flag types will go.
The special types can't be used to form vectors.
Change the numbering scheme for value types to make room for the special
types and add `is_lane()` and `is_special()` classification methods.
The VOID type still has number 0, but it can no longer appear as a
vector lane. It classifies as special now.
The word "scalar" is a bit vague and tends to mean "non-vector". Since
we are about to add new CPU flag value types that can't appear as vector
lanes, make the distinction clear: LaneType represents value types that
can appear as a vector lane.
Also replace the Type::is_scalar() method with an is_vector() method.
Every encoding recipe must specify register constraints on input and
output values.
Generate recipe constraint tables along with the other encoding tables.
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.
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.
Clarify terminology by always referring to a 'Target ISA' instead of just
'Target'. Use 'isa' as a module name instead of 'target' both in Rust and Python
code.
This is only to clarify terminology and not at all because Cargo insists on
using the 'target' sub-directory for build products. Oh, no. Not at all.
Move the CPUMode reference from EncRecipe to the Encoding itself, allowing
EncRecipes to be shared between CPU modes. At least RISC-V should be able to
share some recipes between RV32 and RV64 modes.
Add a typevar_operand argument to the InstructionFormat constructor which
determines the operand used for inferring the controlling type variable.
Identify polymorphic instructions when they are created, determine if the
controlling type variable can be inferred from the typevar_operand, and verify
the use of type variables in the other operands.
Generate type variable summary in the documentation, including how the
controlling type variable is inferred.
We have a two-level type system: OperandKinds and ValueTypes. The value types
only apply to value operands, but there are many more kinds of operands:
immediate numbers, condition codes, basic block references, etc.
The Cretonne meta language is used to describe Cretonne instructions, both the
target independent ones in the base instruction set and real target
instructions.
Start by providing type definitions matching langref, and begin the meta
language reference using autodoc to pull in the PYthon definitions.
