This instruction behaves like icmp fused with brnz, and it can be used
to represent fused compare+branch instruction on Intel when optimizing
for macro-op fusion.
RISC-V provides compare-and-branch instructions directly, and it is
needed there too.
The meaning of format.typevar_operand changes recently to be relative to
value operands only instead of all operands. The Sphinx cton domain
wasn't updated.
Compare a scalar integer to an immediate constant. Both Intel and RISC-V
ISAs have this operation.
This requires the addition of a new IntCompareImm instruction format.
If an instruction doesn't have an associated encoding, use the standard
TargetIsa hook to encode it.
The test still fails if an instruction can't be encoded. There is no
legalization step.
No instruction sets actually have single instructions for materializing
vector constants. You always need to use a constant pool.
Cretonne doesn't have constant pools yet, but it will in the future, and
that is how vector constants should be represented.
Instruction formats are now identified by a signature that doesn't
include the ordering of value operands relative to immediate operands.
This means that the BinaryRev instruction format becomes redundant, so
delete it. The isub_imm instruction was the only one using that format.
Rename it to irsub_imm to make it clear what it does now that it is
printed as 'irsub_imm v2, 45'.
Read the Docs is now using the latest version of Sphinx, so upgrade our
recommended version too.
As of Sphinx 1.4, index entries are 5-tuples instead of 4-tuples. Update
the Cretonne Sphinx domain to generate the new 5-tuples.
Since we're over this compatibility bump, there's no reason to recommend
a specific Sphinx version, so just go back to 'current'.
Add support for two new type variable functions: half_vector() and
double_vector().
Use these two instructions to break down unsupported SIMD types and
build them up again.
Specify the location of arguments as well as the size of stack argument
array needed. The ABI annotations are optional, just like the value
locations.
Remove the Eq implementation for Signature which was only used by a
single parser test.
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.
Include the test file preamble comments when building a filecheck
instance for every function in the file.
This makes it possible to define common regex variables in the preamble
and use these definitions for all the functions.
The copy/spill/fill instructions will be used by the register allocator
for splitting live ranges. The copy instruction is also useful when
rewriting values:
If a primary value is rewritten as a secondary result, a copy
instruction can be used instead:
a = foo x
=>
t, vx1 = call ...
a = copy vx1
Since a primary value must be the first value of an instruction, this
doesn't work:
a = foo x
=>
t, a = call ...
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.
These refer to external functions and function signatures declared in
the preamble. Since we're already using the type names 'Signature' and
'Function', these entity references don't folow the usual EntityData /
Entity naming convention.
The isplit_lohi instruction breaks an integer into two halves. This will
typically be used to get the two halves of an `i64` value on 32-bit
CPUs.
The iconcat_lohi is the reverse operation. It reconstructs the `i64`
from the low and high bits.
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.
