julian-seward1 commented on Issue #1147:
It seems to me that the simplest fix is simply to remove all
NxM
types from CL's type system, whereNxM == 128
, and replace them with a singleV128
type. What benefit does having all these types bring us? They are not useful for typechecking CLIF that is derived from wasm, since wasm allows free intermixing of the types.
julian-seward1 commented on Issue #1147:
(notes copied from #2303):
Disadvantages of using bitcasts:
they make the logic in this file [
code_translator.rs
] fragile: miss out a bitcast for any reason, and there is the risk of the system failing in the verifier. At least for debug builds.in the new backends, they potentially interfere with pattern matching on CLIF -- the patterns need to take into account the presence of bitcast nodes.
in the new backends, they get translated into machine-level vector-register-copy instructions, none of which are actually necessary. We then depend on the register allocator to coalesce them all out.
they increase the total number of CLIF nodes that have to be processed, hence slowing down the compilation pipeline. Also, the extra coalescing work generates a slowdown.
bjorn3 commented on Issue #1147:
Replacing
NxM
withV128
would require a new variant of many instructions for every lane size. The current design allows using the sameiadd
instruction for every integer type both scalar and vector. It is also useful for typechecking CLIF derived from rust, as rust doesn't allow mixing vector types without an explicit transmute.
julian-seward1 commented on Issue #1147:
One longer-term way around that, once the old backend is no longer needed, that would be to abandon the DSL for defining CLIF instructions. And instead define them using a simple Rust enum, in the same way that the new backends define target specific instructions. And for the vector instructions, include a field of type
enum Laneage { I8X16, I16X8, I32X4, I64X2, F versions of the same, etc }
julian-seward1 edited a comment on Issue #1147:
One longer-term way around that, once the old backend is no longer needed, would be to abandon the DSL for defining CLIF instructions. And instead define them using a simple Rust enum, in the same way that the new backends define target specific instructions. And for the vector instructions, include a field of type
enum Laneage { I8X16, I16X8, I32X4, I64X2, F versions of the same, etc }
bjorn3 commented on Issue #1147:
Currently many instructions are both scalar and vector instructions at the same time. For example
iadd
. Adding aLaneage
argument would add unnecessary noise when using scalars only.
Last updated: Nov 22 2024 at 16:03 UTC