Stream: git-wasmtime

Topic: wasmtime / issue #6571 riscv64: Merge vector mask generat...

Wasmtime GitHub notifications bot (Jun 13 2023 at 10:18):

afonso360 opened issue #6571:

Feature

We currently have separate rules for generating vector masks and vector constants. We should merge these rules into the same set of instructions.

Benefit

This would allow us to implement the constant generation logic in a single place, and improve codegen for both use cases.

Implementation

Today we have gen_vec_mask and gen_constant. gen_constant takes a VCodeConstant and that is not a very flexible interface since it requires us to emit a VCode Constant before using it. As far as I understand that means that those constants would always end up in the constant pool.

We could have gen_constant take a byte slice and pattern match based on that. That would allow us to avoid polluting the constant pool, and only materialize the constants there when necessary.

A slight issue with this is that we aren't very good at de-duplicating generated constants, so it would be nice to try and reuse VCodeConstant's when they originate from vconst. (Since that means that they have been de-duplicated beforehand)

We could try making a variant of gen_constant that is fallible but always emits an optimized lowering that is better than a load to the constant. gen_constant could then try that before falling back to loading the de-duplicated constant pool value.

Alternatives

Having these as separate rules is an option, however there are some slightly complex constant generation rules that could be beneficial for mask generation which would be nice not to duplicate.

Wasmtime GitHub notifications bot (Jun 13 2023 at 10:19):

afonso360 edited issue #6571:

Feature

We currently have separate rules for generating vector masks and vector constants. We should merge these rules into the same set of instructions.

Benefit

This would allow us to implement the constant generation logic in a single place, and improve codegen for both use cases.

Implementation

Today we have gen_vec_mask and gen_constant. gen_constant takes a VCodeConstant and that is not a very flexible interface since it requires us to emit a VCode Constant before using it. As far as I understand that means that those constants would always end up in the constant pool.

We could have gen_constant take a byte slice and pattern match based on that. That would allow us to avoid polluting the constant pool, and only materialize the constants there when necessary.

A slight issue with this is that we aren't very good at de-duplicating generated constants, so it would be nice to try and reuse VCodeConstant's when they originate from vconst. (Since that means that they have been de-duplicated beforehand)

We could try making a variant of gen_constant that is fallible but always emits an optimized lowering that is better than a load to the constant. gen_constant could then try that before falling back to loading the de-duplicated constant pool value.

Alternatives

Having these as separate rules is an option, however there are some slightly complex constant generation rules that could be beneficial for mask generation which would be nice not to duplicate.

Wasmtime GitHub notifications bot (Jun 13 2023 at 10:19):

afonso360 edited issue #6571:

Feature

We currently have separate rules for generating vector masks and vector constants. We should merge these together.

Benefit

This would allow us to implement the constant generation logic in a single place, and improve codegen for both use cases.

Implementation

Today we have gen_vec_mask and gen_constant. gen_constant takes a VCodeConstant and that is not a very flexible interface since it requires us to emit a VCode Constant before using it. As far as I understand that means that those constants would always end up in the constant pool.

We could have gen_constant take a byte slice and pattern match based on that. That would allow us to avoid polluting the constant pool, and only materialize the constants there when necessary.

A slight issue with this is that we aren't very good at de-duplicating generated constants, so it would be nice to try and reuse VCodeConstant's when they originate from vconst. (Since that means that they have been de-duplicated beforehand)

We could try making a variant of gen_constant that is fallible but always emits an optimized lowering that is better than a load to the constant. gen_constant could then try that before falling back to loading the de-duplicated constant pool value.

Alternatives

Having these as separate rules is an option, however there are some slightly complex constant generation rules that could be beneficial for mask generation which would be nice not to duplicate.

Wasmtime GitHub notifications bot (Jun 13 2023 at 10:19):

afonso360 labeled issue #6571:

Feature

We currently have separate rules for generating vector masks and vector constants. We should merge these together.

Benefit

This would allow us to implement the constant generation logic in a single place, and improve codegen for both use cases.

Implementation

Today we have gen_vec_mask and gen_constant. gen_constant takes a VCodeConstant and that is not a very flexible interface since it requires us to emit a VCode Constant before using it. As far as I understand that means that those constants would always end up in the constant pool.

We could have gen_constant take a byte slice and pattern match based on that. That would allow us to avoid polluting the constant pool, and only materialize the constants there when necessary.

A slight issue with this is that we aren't very good at de-duplicating generated constants, so it would be nice to try and reuse VCodeConstant's when they originate from vconst. (Since that means that they have been de-duplicated beforehand)

We could try making a variant of gen_constant that is fallible but always emits an optimized lowering that is better than a load to the constant. gen_constant could then try that before falling back to loading the de-duplicated constant pool value.

Alternatives

Having these as separate rules is an option, however there are some slightly complex constant generation rules that could be beneficial for mask generation which would be nice not to duplicate.

Last updated: Dec 13 2025 at 19:03 UTC