Stream: git-wasmtime

Topic: wasmtime / issue #9747 Pulley TODO List

Wasmtime GitHub notifications bot (Dec 05 2024 at 21:16):

alexcrichton added the pulley label to Issue #9747.

Wasmtime GitHub notifications bot (Dec 05 2024 at 21:16):

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

Wasmtime GitHub notifications bot (Dec 05 2024 at 21:17):

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>

Wasmtime GitHub notifications bot (Dec 05 2024 at 21:18):

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.

Wasmtime GitHub notifications bot (Dec 05 2024 at 21:18):

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

~~~

Wasmtime GitHub notifications bot (Dec 05 2024 at 21:20):

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

Wasmtime GitHub notifications bot (Dec 05 2024 at 21:20):

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.

~~~

Wasmtime GitHub notifications bot (Dec 05 2024 at 22:24):

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

~~~

Wasmtime GitHub notifications bot (Dec 05 2024 at 23:06):

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

Wasmtime GitHub notifications bot (Dec 05 2024 at 23:07):

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)

~~~

Wasmtime GitHub notifications bot (Dec 06 2024 at 22:39):

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)

~~~

Wasmtime GitHub notifications bot (Dec 10 2024 at 17:27):

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?

~~~

Wasmtime GitHub notifications bot (Dec 10 2024 at 17:28):

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"

~~~

Wasmtime GitHub notifications bot (Dec 10 2024 at 17:28):

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 remove xload8_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"

~~~

Wasmtime GitHub notifications bot (Dec 10 2024 at 17:40):

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 remove xload8_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"

~~~

Wasmtime GitHub notifications bot (Dec 10 2024 at 17:40):

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 remove xload8_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"

~~~

Wasmtime GitHub notifications bot (Dec 10 2024 at 17:40):

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 remove xload8_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

~~~

Wasmtime GitHub notifications bot (Dec 10 2024 at 17:41):

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 remove xload8_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

~~~

Wasmtime GitHub notifications bot (Dec 11 2024 at 14:21):

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 remove xload8_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

~~~

Wasmtime GitHub notifications bot (Dec 11 2024 at 15:28):

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 remove xload8_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

~~~

Wasmtime GitHub notifications bot (Dec 11 2024 at 22:04):

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 remove xload8_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

~~~

Wasmtime GitHub notifications bot (Dec 11 2024 at 22:05):

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 remove xload8_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]

~~~

Wasmtime GitHub notifications bot (Dec 11 2024 at 22:05):

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 remove xload8_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]

~~~

Wasmtime GitHub notifications bot (Dec 11 2024 at 22:05):

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 remove xload8_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]

~~~

Wasmtime GitHub notifications bot (Dec 11 2024 at 22:54):

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 remove xload8_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]

~~~

Wasmtime GitHub notifications bot (Dec 11 2024 at 22:54):

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 remove xload8_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]

~~~

Wasmtime GitHub notifications bot (Dec 12 2024 at 00:07):

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 remove xload8_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]

~~~

Wasmtime GitHub notifications bot (Dec 12 2024 at 02:04):

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 remove xload8_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

~~~

Wasmtime GitHub notifications bot (Dec 12 2024 at 15:28):

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 remove xload8_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

~~~

Wasmtime GitHub notifications bot (Dec 13 2024 at 21:00):

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 remove xload8_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

~~~

Wasmtime GitHub notifications bot (Dec 13 2024 at 21:11):

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 remove xload8_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

~~~

Wasmtime GitHub notifications bot (Dec 16 2024 at 22:01):

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 remove xload8_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

~~~

Wasmtime GitHub notifications bot (Dec 16 2024 at 23:02):

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 remove xload8_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

Wasmtime GitHub notifications bot (Dec 17 2024 at 01:14):

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 remove xload8_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

Wasmtime GitHub notifications bot (Dec 17 2024 at 20:57):

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 remove xload8_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

Wasmtime GitHub notifications bot (Jan 06 2025 at 18:57):

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 remove xload8_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
• [ ] Implement the wide-arithmetic proposal

Wasmtime GitHub notifications bot (Jan 06 2025 at 21:03):

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
• [x] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation) https://github.com/bytecodealliance/wasmtime/pull/9837
• [ ] 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 remove xload8_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
• [ ] Implement the wide-arithmetic proposal

Wasmtime GitHub notifications bot (Jan 06 2025 at 21:03):

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
• [x] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation) https://github.com/bytecodealliance/wasmtime/pull/9837
• [ ] 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 remove xload8_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
• [ ] Implement the wide-arithmetic proposal
• [ ] Fuzz pulley

Wasmtime GitHub notifications bot (Jan 07 2025 at 21:36):

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
• [x] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation) https://github.com/bytecodealliance/wasmtime/pull/9837
• [ ] 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 remove xload8_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
• [x] Implement the wide-arithmetic proposal https://github.com/bytecodealliance/wasmtime/pull/9944
• [ ] Fuzz pulley

Wasmtime GitHub notifications bot (Jan 09 2025 at 20:17):

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
• [x] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation) https://github.com/bytecodealliance/wasmtime/pull/9837
• [ ] 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 remove xload8_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
• [x] Implement the wide-arithmetic proposal https://github.com/bytecodealliance/wasmtime/pull/9944
• [x] Fuzz pulley https://github.com/bytecodealliance/wasmtime/pull/9966

Wasmtime GitHub notifications bot (Jan 10 2025 at 19:16):

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
• [x] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation) https://github.com/bytecodealliance/wasmtime/pull/9837
• [ ] 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 remove xload8_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"
• [ ] Add support for Pulley to #[wasmtime_test]
• [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
• [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
• [x] Implement the wide-arithmetic proposal https://github.com/bytecodealliance/wasmtime/pull/9944
• [x] Fuzz pulley https://github.com/bytecodealliance/wasmtime/pull/9966

Wasmtime GitHub notifications bot (Jan 10 2025 at 19:16):

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)
• [ ] 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 remove xload8_s32_offset32 instead?
• [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
• [x] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation) https://github.com/bytecodealliance/wasmtime/pull/9837
• [ ] 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"
• [ ] Add support for Pulley to #[wasmtime_test]
• [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
• [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
• [x] Implement the wide-arithmetic proposal https://github.com/bytecodealliance/wasmtime/pull/9944
• [x] Fuzz pulley https://github.com/bytecodealliance/wasmtime/pull/9966

Wasmtime GitHub notifications bot (Jan 10 2025 at 19:16):

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)
• [ ] 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 remove xload8_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] 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
• [x] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation) https://github.com/bytecodealliance/wasmtime/pull/9837
• [ ] Add support for Pulley to #[wasmtime_test]
• [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
• [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
• [x] Implement the wide-arithmetic proposal https://github.com/bytecodealliance/wasmtime/pull/9944
• [x] Fuzz pulley https://github.com/bytecodealliance/wasmtime/pull/9966

Wasmtime GitHub notifications bot (Jan 10 2025 at 19:16):

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)
• [ ] 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 remove xload8_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"
• [ ] Add support for Pulley to #[wasmtime_test]
• [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
• [x] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation) https://github.com/bytecodealliance/wasmtime/pull/9837
• [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
• [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
• [x] Implement the wide-arithmetic proposal https://github.com/bytecodealliance/wasmtime/pull/9944
• [x] Fuzz pulley https://github.com/bytecodealliance/wasmtime/pull/9966

Wasmtime GitHub notifications bot (Jan 13 2025 at 16:59):

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)
• [ ] 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 remove xload8_s32_offset32 instead?
• [x] 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" https://github.com/bytecodealliance/wasmtime/pull/9994
• [ ] Add support for Pulley to #[wasmtime_test]
• [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
• [x] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation) https://github.com/bytecodealliance/wasmtime/pull/9837
• [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
• [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
• [x] Implement the wide-arithmetic proposal https://github.com/bytecodealliance/wasmtime/pull/9944
• [x] Fuzz pulley https://github.com/bytecodealliance/wasmtime/pull/9966

Wasmtime GitHub notifications bot (Jan 13 2025 at 18:51):

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)
• [ ] 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 remove xload8_s32_offset32 instead?
• [ ] Add support for Pulley to #[wasmtime_test]
• [x] 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" https://github.com/bytecodealliance/wasmtime/pull/9994
• [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
• [x] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation) https://github.com/bytecodealliance/wasmtime/pull/9837
• [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
• [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
• [x] Implement the wide-arithmetic proposal https://github.com/bytecodealliance/wasmtime/pull/9944
• [x] Fuzz pulley https://github.com/bytecodealliance/wasmtime/pull/9966

Wasmtime GitHub notifications bot (Jan 15 2025 at 21:09):

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.

• [x] 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)
• [ ] 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 remove xload8_s32_offset32 instead?
• [ ] Add support for Pulley to #[wasmtime_test]
• [x] 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" https://github.com/bytecodealliance/wasmtime/pull/9994
• [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
• [x] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation) https://github.com/bytecodealliance/wasmtime/pull/9837
• [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
• [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
• [x] Implement the wide-arithmetic proposal https://github.com/bytecodealliance/wasmtime/pull/9944
• [x] Fuzz pulley https://github.com/bytecodealliance/wasmtime/pull/9966

Wasmtime GitHub notifications bot (Jan 15 2025 at 21:09):

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.

• [ ] 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 remove xload8_s32_offset32 instead?
• [ ] Add support for Pulley to #[wasmtime_test]
• [x] 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] 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" https://github.com/bytecodealliance/wasmtime/pull/9994
• [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
• [x] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation) https://github.com/bytecodealliance/wasmtime/pull/9837
• [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
• [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
• [x] Implement the wide-arithmetic proposal https://github.com/bytecodealliance/wasmtime/pull/9944
• [x] Fuzz pulley https://github.com/bytecodealliance/wasmtime/pull/9966

Wasmtime GitHub notifications bot (Jan 21 2025 at 18:01):

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.

• [ ] 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 remove xload8_s32_offset32 instead?
• [x] Add support for Pulley to #[wasmtime_test] https://github.com/bytecodealliance/wasmtime/pull/10057
• [x] 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] 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" https://github.com/bytecodealliance/wasmtime/pull/9994
• [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
• [x] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation) https://github.com/bytecodealliance/wasmtime/pull/9837
• [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
• [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
• [x] Implement the wide-arithmetic proposal https://github.com/bytecodealliance/wasmtime/pull/9944
• [x] Fuzz pulley https://github.com/bytecodealliance/wasmtime/pull/9966

Wasmtime GitHub notifications bot (Jan 23 2025 at 17:03):

alexcrichton closed 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.

• [ ] 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 remove xload8_s32_offset32 instead?
• [x] Add support for Pulley to #[wasmtime_test] https://github.com/bytecodealliance/wasmtime/pull/10057
• [x] 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] 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" https://github.com/bytecodealliance/wasmtime/pull/9994
• [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
• [x] Need to restore callee-save state when a trap happens somehow (either via explicit saves or by removing callee-save state in that situation) https://github.com/bytecodealliance/wasmtime/pull/9837
• [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
• [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
• [x] Implement the wide-arithmetic proposal https://github.com/bytecodealliance/wasmtime/pull/9944
• [x] Fuzz pulley https://github.com/bytecodealliance/wasmtime/pull/9966

Wasmtime GitHub notifications bot (Jan 23 2025 at 17:03):

alexcrichton commented on issue #9747:

I think that this issue has served it's purpose and is largely done, so I'm going to close this.

Last updated: Jan 24 2025 at 00:11 UTC