Stream: git-wasmtime

Topic: wasmtime / issue #6527 riscv64: Try matching `vconst`'s i...


view this post on Zulip Wasmtime GitHub notifications bot (Jun 06 2023 at 17:43):

afonso360 opened issue #6527:

:wave: Hey,

I'm filing this as a follow up to #6515.

Feature

In the RISC-V backend for cranelift we have two extractors that match a imm5 that is splatted into a vector. We currently just match splat+iconst, but we could match the equivalent vconst.

Benefit

This would improve codegen for the instructions that use these extractors. Which is a lot of them. Instead of emitting a VConst we would be able to fold that value in the immediate field of the instruction.

Implementation

I'm not entirely sure if this requires OR patterns in ISLE? Since we want to keep matching splat+iconst as well. Otherwise we can always build the extractor as an external extractor.

Something that might be worth taking into account is that the RISC-V backend deals with a larger variety of vconst's since we implement SIMD instructions generically, so having a vector that is i8x2 is not unexpected, and most of the rules work well for these sizes, as well as the more common i8x16.

Alternatives

We can duplicate the rules that currently use replicated_* but that is slightly less appealing.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 06 2023 at 17:43):

afonso360 labeled issue #6527:

:wave: Hey,

I'm filing this as a follow up to #6515.

Feature

In the RISC-V backend for cranelift we have two extractors that match a imm5 that is splatted into a vector. We currently just match splat+iconst, but we could match the equivalent vconst.

Benefit

This would improve codegen for the instructions that use these extractors. Which is a lot of them. Instead of emitting a VConst we would be able to fold that value in the immediate field of the instruction.

Implementation

I'm not entirely sure if this requires OR patterns in ISLE? Since we want to keep matching splat+iconst as well. Otherwise we can always build the extractor as an external extractor.

Something that might be worth taking into account is that the RISC-V backend deals with a larger variety of vconst's since we implement SIMD instructions generically, so having a vector that is i8x2 is not unexpected, and most of the rules work well for these sizes, as well as the more common i8x16.

Alternatives

We can duplicate the rules that currently use replicated_* but that is slightly less appealing.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 03 2023 at 21:28):

afonso360 closed issue #6527:

:wave: Hey,

I'm filing this as a follow up to #6515.

Feature

In the RISC-V backend for cranelift we have two extractors that match a imm5 that is splatted into a vector. We currently just match splat+iconst, but we could match the equivalent vconst.

Benefit

This would improve codegen for the instructions that use these extractors. Which is a lot of them. Instead of emitting a VConst we would be able to fold that value in the immediate field of the instruction.

Implementation

I'm not entirely sure if this requires OR patterns in ISLE? Since we want to keep matching splat+iconst as well. Otherwise we can always build the extractor as an external extractor.

Something that might be worth taking into account is that the RISC-V backend deals with a larger variety of vconst's since we implement SIMD instructions generically, so having a vector that is i8x2 is not unexpected, and most of the rules work well for these sizes, as well as the more common i8x16.

Alternatives

We can duplicate the rules that currently use replicated_* but that is slightly less appealing.


Last updated: Oct 23 2024 at 20:03 UTC