Closed abrown closed 4 years ago
One downside of this is that it requires new instructions for signed<->unsigned casts. These would need to exist in the IR, but they'd be effectively no-op instructions, so we'd likely end up teaching pattern-matching code, GVN, and other things to look past them, and to teach register allocation to coalesce them like copies.
Also, since wasm doesn't have signed/unsigned types, wasm translation would be a little awkward, because at the point where we see eg. an i32.load
, we wouldn't know whether to give it a signed or unsigned type until we see a user of the loaded value that cares about the signedness. So we'd either have to lookahead, or we'd have to guess and insert signed<->unsigned casts to fix things up when we guess wrong.
since wasm doesn't have signed/unsigned types, wasm translation would be a little awkward
Yup. Closing this; it would be nice to have to reduce the number of Cranelift instructions but I see what you mean by the added awkwardness.
Feature
Add unsigned integer types to the Cranelift type system.
Benefit
Halve the number of cranelift instructions of the form
uload*
/sload*
,uadd_sat
/sadd_sat
, etc.Implementation
The real question would be whether the
Type
struct (cranelift-codegen/src/ir/types.rs
) has enough index space to fit all of the new unsigned variants; if it does, the work could proceed along the lines of:cranelift-codegen/meta/src/shared/types.rs
to includeSignedInt
andUnsignedInt
enumsLaneType
incranelift-codegen/meta/src/cdsl/types.rs
cranelift-codegen/meta/src/gen_types.rs
cranelift-codegen/src/ir/types.rs
u*
andi*
u32
vsi32
controlling type to determine the encodingAlternatives
This is more an RFC than a real proposal so the alternative is to leave things as they are.