alexcrichton added the pulley label to Issue #9747.
alexcrichton opened issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
- [ ] Move sp/fp/lr/special regs out of the general purpose register set -- https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar -- https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050
github-actions[bot] commented on issue #9747:
Subscribe to Label Action
cc @fitzgen
<details>
This issue or pull request has been labeled: "pulley"Thus the following users have been cc'd because of the following labels:
- fitzgen: pulley
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
- [ ] Move sp/fp/lr/special regs out of the general purpose register set -- https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar -- https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
fitzgen edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
- [ ] Move sp/fp/lr/special regs out of the general purpose register set -- https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar -- https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
```[tasklist]Tasks
~~~
fitzgen edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
```[tasklist] ### Tasks
fitzgen edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
- [ ] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target~~~
alexcrichton commented on issue #9747:
Notes for big-endian:
- Need to add big-endian targets for Cranelift -- https://github.com/bytecodealliance/target-lexicon/pull/115
- Pulley loads/stores will all have annotated endianness, nothing is "native endian"
- New big-endian loads/stores to get added under the "extended" opcode space
- Cranelift will use its configuration to select the appropriate pulley instruction, e.g. "native endianness" is whatever the configured target uses
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
- [ ] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits?~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
~~~
fitzgen edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Get all
.wast
tests passing under Pulley!- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
~~~
fitzgen edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] **Get all
.wast
tests passing under Pulley!**- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
~~~
fitzgen edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] **Get all
.wast
tests passing under Pulley!**- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target~~~
fitzgen edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] **Get all
.wast
tests passing under Pulley!!!!**- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target~~~
fitzgen edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9783
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [ ] Enable Cranelift
runtest
support~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [x] Enable Cranelift
runtest
support -- https://github.com/bytecodealliance/wasmtime/pull/9795~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [ ] Enable Cranelift
runtest
support- [ ] Run the full
all
test suite on 32-bit platforms- [ ] Add support for Pulley to
#[wasmtime_test]
~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [ ] Enable Cranelift
runtest
support https://github.com/bytecodealliance/wasmtime/pull/9795- [ ] Run the full
all
test suite on 32-bit platforms- [ ] Add support for Pulley to
#[wasmtime_test]
~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [ ] Better debugging support, e.g. print the register state between instructions and print each instruction.
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [x] Enable Cranelift
runtest
support https://github.com/bytecodealliance/wasmtime/pull/9795- [ ] Run the full
all
test suite on 32-bit platforms- [ ] Add support for Pulley to
#[wasmtime_test]
~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [x] Better debugging support, e.g. print the register state between instructions and print each instruction. https://github.com/bytecodealliance/wasmtime/pull/9796
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [ ] Enable Cranelift
runtest
support https://github.com/bytecodealliance/wasmtime/pull/9795- [ ] Run the full
all
test suite on 32-bit platforms- [ ] Add support for Pulley to
#[wasmtime_test]
~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [x] Better debugging support, e.g. print the register state between instructions and print each instruction. https://github.com/bytecodealliance/wasmtime/pull/9796
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target - https://github.com/bytecodealliance/wasmtime/pull/9759- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [ ] Enable Cranelift
runtest
support https://github.com/bytecodealliance/wasmtime/pull/9795- [ ] Run the full
all
test suite on 32-bit platforms- [ ] Add support for Pulley to
#[wasmtime_test]
~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [x] Better debugging support, e.g. print the register state between instructions and print each instruction. https://github.com/bytecodealliance/wasmtime/pull/9796
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target - https://github.com/bytecodealliance/wasmtime/pull/9759- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [x] Enable Cranelift
runtest
support https://github.com/bytecodealliance/wasmtime/pull/9795- [ ] Run the full
all
test suite on 32-bit platforms- [ ] Add support for Pulley to
#[wasmtime_test]
~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [x] Better debugging support, e.g. print the register state between instructions and print each instruction. https://github.com/bytecodealliance/wasmtime/pull/9796
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [ ] Enable Cranelift
runtest
support https://github.com/bytecodealliance/wasmtime/pull/9795- [ ] Run the full
all
test suite on 32-bit platforms- [ ] Add support for Pulley to
#[wasmtime_test]
- [ ] Figure out story for threading -- loads/stores all need to be at least with a "relaxed" atomicity
~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [x] Better debugging support, e.g. print the register state between instructions and print each instruction. https://github.com/bytecodealliance/wasmtime/pull/9796
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [x] Enable Cranelift
runtest
support https://github.com/bytecodealliance/wasmtime/pull/9795- [ ] Run the full
all
test suite on 32-bit platforms- [ ] Add support for Pulley to
#[wasmtime_test]
- [ ] Figure out story for threading -- loads/stores all need to be at least with a "relaxed" atomicity
~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details (also cc https://github.com/bytecodealliance/wasmtime/pull/9806)
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [x] Better debugging support, e.g. print the register state between instructions and print each instruction. https://github.com/bytecodealliance/wasmtime/pull/9796
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [x] Enable Cranelift
runtest
support https://github.com/bytecodealliance/wasmtime/pull/9795- [ ] Run the full
all
test suite on 32-bit platforms- [ ] Add support for Pulley to
#[wasmtime_test]
- [ ] Figure out story for threading -- loads/stores all need to be at least with a "relaxed" atomicity
~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details (also cc https://github.com/bytecodealliance/wasmtime/pull/9806)
- [ ] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details
- [x] Better debugging support, e.g. print the register state between instructions and print each instruction. https://github.com/bytecodealliance/wasmtime/pull/9796
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [x] Enable Cranelift
runtest
support https://github.com/bytecodealliance/wasmtime/pull/9795- [ ] Run the full
all
test suite on 32-bit platforms- [ ] Add support for Pulley to
#[wasmtime_test]
- [x] Figure out story for threading -- loads/stores all need to be at least with a "relaxed" atomicity -- https://github.com/bytecodealliance/wasmtime/pull/9818
~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
```[tasklist]
Tasks
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details (also cc https://github.com/bytecodealliance/wasmtime/pull/9806)
- [x] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details -- https://github.com/bytecodealliance/wasmtime/pull/9836
- [x] Better debugging support, e.g. print the register state between instructions and print each instruction. https://github.com/bytecodealliance/wasmtime/pull/9796
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [x] Enable Cranelift
runtest
support https://github.com/bytecodealliance/wasmtime/pull/9795- [ ] Run the full
all
test suite on 32-bit platforms- [ ] Add support for Pulley to
#[wasmtime_test]
- [ ] Figure out story for threading -- loads/stores all need to be at least with a "relaxed" atomicity
~~~
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details (also cc https://github.com/bytecodealliance/wasmtime/pull/9806)
- [x] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details -- https://github.com/bytecodealliance/wasmtime/pull/9836
- [x] Better debugging support, e.g. print the register state between instructions and print each instruction. https://github.com/bytecodealliance/wasmtime/pull/9796
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [x] Enable Cranelift
runtest
support https://github.com/bytecodealliance/wasmtime/pull/9795- [ ] Run the full
all
test suite on 32-bit platforms- [ ] Add support for Pulley to
#[wasmtime_test]
- [x] Figure out story for threading -- loads/stores all need to be at least with a "relaxed" atomicity -- https://github.com/bytecodealliance/wasmtime/pull/9818
alexcrichton edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details (also cc https://github.com/bytecodealliance/wasmtime/pull/9806)
- [x] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details -- https://github.com/bytecodealliance/wasmtime/pull/9836
- [x] Better debugging support, e.g. print the register state between instructions and print each instruction. https://github.com/bytecodealliance/wasmtime/pull/9796
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [x] Enable Cranelift
runtest
support https://github.com/bytecodealliance/wasmtime/pull/9795- [X] Run the full
all
test suite on 32-bit platforms -- https://github.com/bytecodealliance/wasmtime/pull/9837- [ ] Add support for Pulley to
#[wasmtime_test]
- [x] Figure out story for threading -- loads/stores all need to be at least with a "relaxed" atomicity -- https://github.com/bytecodealliance/wasmtime/pull/9818
fitzgen edited issue #9747:
I'd like a place to throw small items as I see them and to collect various TODO items during the development of Pulley. For now this will serve that location. My hope is that this list is TODO items which pertain to code in-tree and are less-so about wishlist items of what's yet to fill in. For example this won't track missing pulley work (e.g. all wasm proposals at this time). Unsure if this style of issue will work out.
- [ ] Support building Wasmtime with the Pulley interpreter but not the Pulley compiler
- [ ] Move sp/fp/lr/special regs out of the general purpose register set; see https://github.com/bytecodealliance/wasmtime/pull/9658#pullrequestreview-2482824188 for details (also cc https://github.com/bytecodealliance/wasmtime/pull/9806)
- [x] Assert in call lowering that pulley<->pulley is always tail-to-tail or similar; see https://github.com/bytecodealliance/wasmtime/pull/9665#discussion_r1871969050 for details -- https://github.com/bytecodealliance/wasmtime/pull/9836
- [x] Better debugging support, e.g. print the register state between instructions and print each instruction. https://github.com/bytecodealliance/wasmtime/pull/9796
- [x] Support big-endian - will need to add
pulley{64,32}be
targets to target-lexicon, then add big-endian loads/stores, then update the CLIF backend to delegate to the right endianness based on the target- [ ] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation)
- [ ] Evaluate 32-bit platforms and the decision to "only write low 32-bits". If we write the full 64-bit width of registers does it actually have a performance loss? Is it worth burning opcode space for opcodes that only write the low-32 instead of high 64? Should we split opcodes like
xconst8
into one that writes 64-bits and one that writes 32-bits? Should we removexload8_s32_offset32
instead?- [ ] Explore adding new addressing modes (e.g. register + register). Should be based on an evaluation of what wasm loads/stores do probably. Perhaps even fold a trapping arithmetic into one macro-op for "do the wasm load on 32-bit" and "do the wasm load on 64-bit"
- [x] Enable Cranelift
runtest
support https://github.com/bytecodealliance/wasmtime/pull/9795- [X] Run the full
all
test suite on 32-bit platforms -- https://github.com/bytecodealliance/wasmtime/pull/9837- [ ] Add support for Pulley to
#[wasmtime_test]
- [x] Figure out story for threading -- loads/stores all need to be at least with a "relaxed" atomicity -- https://github.com/bytecodealliance/wasmtime/pull/9818
Last updated: Dec 23 2024 at 13:07 UTC