There are two kinds of entity maps:
- A primary map is used to allocate entity references and store the primary
entity data. This map only grows when adding new entities with 'push'.
- A secondary map contains additional information about entities in a primary
map. This map always grows with 'ensure', making default entries for any
unknown primary entities.
Only require the 'Default + Clone' traits for values stored in a secondary map.
Also remove the 'grow automatically' feature of the IndexMut implementation.
This means that clients need to call 'ensure' whenever using a potentially
unknown entity reference.
The 'grow automatically' feature could not be implemented for the Index trait,
and it seems unfortunate to have different semantics for Index and IndexMut.
The Layout also handles EBB layout, so new append_ebb calls are necessary.
- Rewrite callers to use the public data member 'layout'.
- Implement Debug for Function in terms of the write module to avoid deriving
it.
This is the opposite of unwrap(). It converts the ad-hoc null references like
NO_EBB and NO_INST into the more standard Option<Ebb> type which unfortunately
takes twice as much space in data structures.
This supports the pattern of creating structs wrapping a u32 and using them as
indexes into a vector of entities. These entity references should implement the
EntityRef trait.
The EntityMap is a generic map from an EntityRef to some value type. It expects
densely indexed entities and uses a Vec to represent the mapping compactly.
It is possible to return multiple values from a function, so ReturnData contains
a VariableArgs instance.
We don't want return instructions to appear as 'return (v1)', so tweak the
printing of VariableArgs so the parantheses are added externally.
We llow forward references to values and EBBs, so it is not possible to rewrite
these from the source domain to the in-memory domain during parsing.
Instead go through all the instructions after parsing everything and rewrite the
value and EBB references when everything has been created and mapped.
This instruction uses two type variables: input and output. Make sure that our
parser can handle it. The output type variable annotation is mandatory.
Add a ValueTypeSet::example() method which is used to provide better diagnostics
for a missing type variable.
Add new intcc and floatcc operand types for the immediate condition codes on
these instructions.
Add new IntCompare and FloatCompare instruction formats.
Add a generic match_enum() parser function that can match any identifier-like
enumerated operand kind that implements FromStr.
Define the icmp and fcmp instructions in case.py. Include documentation for the
condition codes with these two instructions.
The icmp and fmp instructions use different kinds of condition codes because
integers and floating point values behave differently.
Add a CondCode trait implementing shared behavior.
Instructions that don't produce any result values are marked with first_type() =
VOID. The inst_results() iterator should not return any values for such
instructions.
The 'cton-util cat' command parses the given files and writes them out again to
stdout. This has the effect of reformatting and stripping comments.
Fix a writer bug that inverted the blank line before the first EBB.
Add an external dependency to the docopt package and use it for a scaffold
command line interface for the cton-util command.
I am not too happy about taking external dependencies, and docopt pulls in 13
other packages. However, I really don't want to be writing command line parsers,
and as long as the external dependencies are confined to the tools crate, we
should be fine.
The core cretonne crate should stay free of external dependencies to avoid
trouble with embedding it.
Implement a basic 'cat' subcommand which currently behaves like unix 'cat'. It
will gain parser powers soon.
Replace the make_multi_inst() function with a make_inst_results() which uses
the constraint system to create the result values. A typevar argument ensures
that this function does not infer anything from the instruction data arguments.
These arguments may not be valid during parsing.
Implement basic type inference in the parser. If the designated value operand
on a polymorphic instruction refers to a known value, use that to infer the
controlling type variable.
This simple method of type inference requires the operand value to be defined
above the use in the text. Since reordering the EBBs could place a dominating
EBB below the current one, this is a bit fragile. One possibility would be to
require the value is defined in the same EBB. In all other cases, the
controlling typevar should be explicit.
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.
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.
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.
