Use (Function, Details) in place of the aggregrate DetailedFunction.
It turns out that some tests want to clone and manipulate the function
while the details never change.
The result from parsing a function is now a DetailedFunction which
includes all comments that can be associated with an entity.
Comments before the first function are ignored, everything else is
associated with the preceeding entity.
The parse_functions() function still returns plain functions.
Export a single function: parse_functions() which results a vector of
functions parsed from the source string.
Hide the parser and lexer modules. They are not useful to external
clients.
- Add a ir::jumptable module with a JumpTableData struct representing the vector
of destinations.
- Add an entity map of jump tables to the Function.
- Parse and write jump tables in the function preamble.
- Rewrite EBB references in jumptables after parsing.
Replace the three tables instructions, extended_basic_blocks, and
extended_values with a single 'dfg' public member.
Clients using Function are changed to refer to func.layout and func.dfg
respectively.
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.
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.
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.
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.
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.
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.
Avoid gathering too much code in repr.rs.
The `entities` module contains entity reference types, and the `instructions`
module contains instruction opcodes and formats.
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.
