Naming is interesting here. Since 'truncate' refers to removing the least
significant digits, use 'ireduce' instead. The 'extend' use is fairly
established. Don't abbreviate, avoid unfortunate modern vernacular.
Move test-all.sh to the top level directory, and also run the parser tests from
this script.
Use a release build of cton-util to run the parser tests. As we accumulate many
tests in the tests directory tree, this will mean they can still be run quickly.
Point Travis config to the new test script.
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.
These instruction formats take immediate lane index operands. We store these as
u8 fields and require them to be in decimal format in the source. No hexadecimal
lane indexes are supported.
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.
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
