cfallin commented on Issue #1852:
This is wrong.
i128
is supposed to be stored as twoi64
, just likei64
is supposed to be stored as twoi32
on 32bit systems. Storing it in a vector register makes it a lot harder to generate efficient math operations fori128
.Fair enough, removed. It was used internally (produced by and matched by the ABI code) to communicate to
store_stack
/load_stack
that a store/load needs to handle the whole 128-bit vector register, in the case that the regalloc cannot provide a vreg/type associated with a spill. In other words this match arm would not have been triggered by anI128
in the incoming CLIF. But the regalloc should not do this in practice (it only lacks a vreg for a spill/reload when it is a reference from a realreg being spilled to a stackmap slot), so we can just remove the match case. I would expect that when we implement trueI128
support, we would lower it to 64-bit ops, and the spill/reload code would not need to reason aboutI128
s.
cfallin commented on Issue #1852:
Rebased to latest and updated to use support in
regalloc.rs
that was just merged. The PR to do a new release of regalloc is pending, so this depends on the bytecodealliance/regalloc.rs repo and git hash directly, to let CI work; will update this before a any merge.@julian-seward1, this should be ready for review now!
cfallin commented on Issue #1852:
(Actually, spoke too quickly re: regalloc -- we just released 0.0.27 so the dep in this PR can use that now.)
cfallin commented on Issue #1852:
Rebased again after changes to
x64
backend.@julian-seward1 or @bnjbvr, would you mind reviewing this soon before we land additional new-backend PRs, to reduce the rebase overhead somewhat? Thanks!
cfallin commented on Issue #1852:
Addressed, thanks!
Last updated: Nov 22 2024 at 16:03 UTC