During parsing, it is possible to see instruction operands that reference
values or EBBs that have not been created yet. These references have to be
resolved by a second pass following parsing once all EBBs and values have been
created.
To prepare for this second pass, start creating Ebb and Value references that
use the numbering from the source file rather than the in-memory real
references. Maintain Value -> Value and Ebb -> Ebb mappings. This makes it
possible to store source-numbered Ebb and Value references in instructions.
All other entities are created in the preamble, so they should have been created
before they are referenced.
Add an Opcode::constraints() method which returns an OpcodeConstraints object.
This object provides information on instruction polymorphism and how many
results is produced.
Generate a list of TypeSet objects for checking free type variables. The type
sets are parametrized rather than being represented as fully general sets.
Add UniqueTable and UniqueSeqTable classes to the meta code generator. Use for
compressing tabular data by removing duplicates.
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.
This will eventualy be used for add-with-carry and add-with-overflow type
instructions. For now it only serves as a representative of instruction formats
that have multiple_results=True and boxed_storage=False at the same time.
Accessors for shared fields and multiple results can be generated automatically.
Add a 'boxed_storage' flag to the instruction format definitions to enable
generated code to access 'data'.
Create map entries for ebbs and values as they are defined, but leave ebb and
value operands unresolved on instructions as they are parsed. Instruction
operands can refer to ebbs and values that may not have been defined yet.
Don't infer or check result types yet.
Place instructions in a doubly linked list and point to the first and last
instruction in an EBB.
Provide an iterator for all the EBBs too. This doesn't reflect the layout
order, but simply the order blocks were created.
These two enums must have identical variants. One is generated from the
instruction formats in meta/cretonne/formats.py, the other defines the contents
of an instruction.
Emit a conversion from InstructionData to InstructionFormat which also serves
to verify the correspondence. Rustc will error is the match is not complete.
Avoid gathering too much code in repr.rs.
The `entities` module contains entity reference types, and the `instructions`
module contains instruction opcodes and formats.
This is a no-payload enum which will have the same variants as InstructionData.
This makes it possible to talk about the format of an instruction without
actually creating an InstructionData instance.
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.
Values that are defined together are represented as a singly linked list. These
lists appear in:
- Instructions with multiple result values. The first result value is special, and the
following results form a linked list of Def extended_value table entries.
- EBB arguments are represented as a linked list of Argument extended_value
table entries. The EbbData struct has pointers to the first and last argument
to allow fast insertion at both ends.
Add a Values iterator type whicih can enumerate both kinds of value lists.
When Function serves as a container for IL entities, use the Index trait to
translate a reference class to a Data object.
Works for:
- StackSlot -> StackSlotData
- Inst -> InstructionData
libctonfile -> libreader.
This library will only provide .cton file reading/parsing services which are
not needed after deployment.
Code for writing .cton files lives in the main cretonne library because it is
fairly small, and because it is useful for extracting test cases from a
deployed library.
Add a stack slot array to repr::Function, use repr::StackSlot to reference them.
Parse stack slot declarations in the function preamble, add them to the
function.
Add a new `Context` struct which keeps track of mappings between identifiers
used in the file and real references.
Don't use assertions to enforce the limits on SIMD lanes in a type, Type is too
fundamental for that. Instead, the Vector-forming by() method returns an
Optional<Type>, and None if the requested SIMD vector is not valid.
Same for Type::half_vector().
These are bitwise exact conversions from string to immediates, implementing the
inverse of the Display trait.
Only accept hexadecimal floating point numbers to avoid issues with rounding
when converting decimal numbers to binary.
The src/tools directory contains the cretonne-tools crate which will build
binaries for testing cretonne.
The src/libctonfile directory contains the ctonfile library crate which
provides reading and writing of .cton files.
Use a simple quadratically probed, open addressed hash table. We could use a
parfect hash function, but it would take longer to compute in Python, and this
is not in the critical path performancewise.
