cfallin opened issue #4126:
Currently, adding a new backend to Cranelift entails at least the following:
- Defining an "assembler library" centered on a new
MachInst
type, with all the tedious and error-prone work around that (see #4125);- Defining the register set;
- Defining glue constructors in ISLE to generate these instructions;
- Defining lowering rules in ISLE;
- Implementing top-level driver logic for the ISLE backend;
- Implementing a bunch of miscellaneous traits and types, such as the
LabelUse
relocation framework;- Implementing an ABI binding;
- Implementing unwind info and debuginfo specifics for this platform;
- implementing whatever is necessary in the Cranelift embedder (e.g. for wasmtime, at least the fiber support, trap handling details, and object-file details like relocations).
While some of this is unavoidable, we should strive as much as possible to factor out the commonalities, and centralize things otherwise, and write documentation walking through the whole process.
In particular:
- Solving #4125 would allow the backend author to follow a declarative approach to sketch the instruction format, then "chase the type errors" to fill out the emission details, without too much fear of mistakes in the glue;
- Generating ISLE constructors for the machine instructions automatically would help a lot;
- Providing "default implementations" for a lot of the
MachBackend
trait, and factoring out the rest into smaller traits, would eliminate a lot of the duplication that currently exists.
cfallin labeled issue #4126:
Currently, adding a new backend to Cranelift entails at least the following:
- Defining an "assembler library" centered on a new
MachInst
type, with all the tedious and error-prone work around that (see #4125);- Defining the register set;
- Defining glue constructors in ISLE to generate these instructions;
- Defining lowering rules in ISLE;
- Implementing top-level driver logic for the ISLE backend;
- Implementing a bunch of miscellaneous traits and types, such as the
LabelUse
relocation framework;- Implementing an ABI binding;
- Implementing unwind info and debuginfo specifics for this platform;
- implementing whatever is necessary in the Cranelift embedder (e.g. for wasmtime, at least the fiber support, trap handling details, and object-file details like relocations).
While some of this is unavoidable, we should strive as much as possible to factor out the commonalities, and centralize things otherwise, and write documentation walking through the whole process.
In particular:
- Solving #4125 would allow the backend author to follow a declarative approach to sketch the instruction format, then "chase the type errors" to fill out the emission details, without too much fear of mistakes in the glue;
- Generating ISLE constructors for the machine instructions automatically would help a lot;
- Providing "default implementations" for a lot of the
MachBackend
trait, and factoring out the rest into smaller traits, would eliminate a lot of the duplication that currently exists.
cfallin labeled issue #4126:
Currently, adding a new backend to Cranelift entails at least the following:
- Defining an "assembler library" centered on a new
MachInst
type, with all the tedious and error-prone work around that (see #4125);- Defining the register set;
- Defining glue constructors in ISLE to generate these instructions;
- Defining lowering rules in ISLE;
- Implementing top-level driver logic for the ISLE backend;
- Implementing a bunch of miscellaneous traits and types, such as the
LabelUse
relocation framework;- Implementing an ABI binding;
- Implementing unwind info and debuginfo specifics for this platform;
- implementing whatever is necessary in the Cranelift embedder (e.g. for wasmtime, at least the fiber support, trap handling details, and object-file details like relocations).
While some of this is unavoidable, we should strive as much as possible to factor out the commonalities, and centralize things otherwise, and write documentation walking through the whole process.
In particular:
- Solving #4125 would allow the backend author to follow a declarative approach to sketch the instruction format, then "chase the type errors" to fill out the emission details, without too much fear of mistakes in the glue;
- Generating ISLE constructors for the machine instructions automatically would help a lot;
- Providing "default implementations" for a lot of the
MachBackend
trait, and factoring out the rest into smaller traits, would eliminate a lot of the duplication that currently exists.
cfallin labeled issue #4126:
Currently, adding a new backend to Cranelift entails at least the following:
- Defining an "assembler library" centered on a new
MachInst
type, with all the tedious and error-prone work around that (see #4125);- Defining the register set;
- Defining glue constructors in ISLE to generate these instructions;
- Defining lowering rules in ISLE;
- Implementing top-level driver logic for the ISLE backend;
- Implementing a bunch of miscellaneous traits and types, such as the
LabelUse
relocation framework;- Implementing an ABI binding;
- Implementing unwind info and debuginfo specifics for this platform;
- implementing whatever is necessary in the Cranelift embedder (e.g. for wasmtime, at least the fiber support, trap handling details, and object-file details like relocations).
While some of this is unavoidable, we should strive as much as possible to factor out the commonalities, and centralize things otherwise, and write documentation walking through the whole process.
In particular:
- Solving #4125 would allow the backend author to follow a declarative approach to sketch the instruction format, then "chase the type errors" to fill out the emission details, without too much fear of mistakes in the glue;
- Generating ISLE constructors for the machine instructions automatically would help a lot;
- Providing "default implementations" for a lot of the
MachBackend
trait, and factoring out the rest into smaller traits, would eliminate a lot of the duplication that currently exists.
Last updated: Dec 23 2024 at 12:05 UTC