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
andgen_constant
.gen_constant
takes aVCodeConstant
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 fromvconst
. (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.
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
andgen_constant
.gen_constant
takes aVCodeConstant
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 fromvconst
. (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.
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
andgen_constant
.gen_constant
takes aVCodeConstant
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 fromvconst
. (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.
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
andgen_constant
.gen_constant
takes aVCodeConstant
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 fromvconst
. (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 23 2024 at 13:07 UTC