Re: [PATCH] vect: Check that vector factor is a compile-time constant

[Michael Collison <collison@rivosinc.com>]

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