Hi Jeff,
We do not have two independent implementations: my work is 100% based on
the vector intrinsic foundation in upstream GCC. In fact I have only
added two core patterns, vector add and subtract, that are based on the
existing vector intrinsics implementation:
(define_expand "add<mode>3"
[(match_operand:VI 0 "register_operand")
(match_operand:VI 1 "register_operand")
(match_operand:VI 2 "vector_arith_operand")]
"TARGET_VECTOR"
{
using namespace riscv_vector;
rtx merge = gen_rtx_UNSPEC (<MODE>mode, gen_rtvec (1, const0_rtx),
UNSPEC_VUNDEF);
rtx vl = emit_vlmax_vsetvl (<MODE>mode);
rtx mask_policy = get_mask_policy_no_pred();
rtx tail_policy = get_tail_policy_no_pred();
rtx mask = CONSTM1_RTX(<VM>mode);
rtx vlmax_avl_p = get_avl_type_rtx(NONVLMAX);
emit_insn(gen_pred_add<mode>(operands[0], mask, merge, operands[1],
operands[2],
vl, tail_policy, mask_policy, vlmax_avl_p));
DONE;
})
This pattern leverages the existing vector intrinsics framework. The
bulk of the changes are the cost model, and target macros. The cost
model is based on Juzhe's work.
The point I am making is the auto-vectorization work is no more
experimental than the intrinsics work which is still being merged.
On 2/22/23 23:01, Jeff Law wrote:
On 2/22/23 10:54, Michael Collison wrote:
Juzhe,
I disagree with this comment. There are many stakeholders for
autovectorization and waiting until GCC 14 is not a viable solution
for us as well as other stakeholders ready to begin work on
autovectorization.
As we discussed I have been moving forward with patches for
autovectorization and am preparing to send them to gcc-patches. This
assert is preventing code from compiling and needs to be addressed.
If you have a solution in either the RISCV backend or in this file
can you please present it?
I don't necessarily think it means waiting for gcc-14, but it does
mean waiting for gcc-13 to branch and gcc-14 development to open. I
would object to anyone trying to push forward an autovec
implementation into gcc-13. We're well past that point IMHO, even if
the changes only affected the RISC-V backend.
Given that it looks like we have two independent implementations we're
almost certainly going to have to sit down with both, evaluate both
from a quality of code viewpoint and benchmark them both and
ultimately choose one implementation or the other, or maybe even some
mixing and matching.
I would strongly suggest that both groups have implementations we can
start evaluating from a design/implementation standpoint relatively
soon. Ideally both groups would actually have branches in the repo
that are regularly updated with their current implementation.
While I have a great interest in seeing an autovec implementation move
forward as soon as possible after gcc-14 development opens, I have no
opinions at this point about either of the two existing implementations.
Jeff
