Thanks, although I still have concern about that we should consider
check on movmisalign with STRICT_ALIGNMENT, but I am ok with this for
now, we can always fix that if got future issues.

committed to trunk

On Tue, May 9, 2023 at 11:22 PM 钟居哲 <juzhe.zh...@rivai.ai> wrote:
>
> No, I don't think so. Some testcases the reason I added -fno-vect-cost-model 
> here is
> because we don't have enough patterns to enable some auto-vectorizations.
> I add   -fno-vect-cost-model to force enable auto-vectorizations for such 
> cases for testing.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: Kito Cheng
> Date: 2023-05-09 22:36
> To: juzhe.zhong
> CC: gcc-patches@gcc.gnu.org; pal...@dabbelt.com; jeffreya...@gmail.com; 
> rdapp....@gmail.com
> Subject: Re: [PATCH V2] RISC-V: Fix incorrect implementation of 
> TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
> One more question from me: should we just add  -fno-vect-cost-model to
> AUTOVEC_TEST_OPTS?
>
> On Tue, May 9, 2023 at 10:29 PM Kito Cheng <kito.ch...@gmail.com> wrote:
> >
> > Oh, checked default_builtin_support_vector_misalignment and I realized
> > we can just remove riscv_support_vector_misalignment at all...
> >
> >
> > On Tue, May 9, 2023 at 10:18 PM juzhe.zhong <juzhe.zh...@rivai.ai> wrote:
> > >
> > > riscv_support_vector_misalignment update makes some of the testcase check 
> > > fail. I have checked the those fails, they are reasonable. So I include 
> > > test case adapt in this patch.
> > > ---- Replied Message ----
> > > FromKito Cheng<kito.ch...@gmail.com>
> > > Date05/09/2023 21:54
> > > tojuzhe.zh...@rivai.ai<juzhe.zh...@rivai.ai>
> > > ccgcc-patc...@gcc.gnu.org<gcc-patches@gcc.gnu.org>,
> > > pal...@dabbelt.com<pal...@dabbelt.com>,
> > > jeffreya...@gmail.com<jeffreya...@gmail.com>,
> > > rdapp....@gmail.com<rdapp....@gmail.com>
> > > SubjectRe: [PATCH V2] RISC-V: Fix incorrect implementation of 
> > > TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
> > > I am ok with both changes but I tried to build some test cases, and it
> > > seems the changes are caused by options update, not caused by the
> > > riscv_support_vector_misalignment update? so I would like to see the
> > > testcase should split out into a separated patch.
> > >
> > > > +/* Return true if the vector misalignment factor is supported by the
> > > > +   target.  */
> > > >  bool
> > > >  riscv_support_vector_misalignment (machine_mode mode,
> > > >                                    const_tree type ATTRIBUTE_UNUSED,
> > > >                                    int misalignment,
> > > >                                    bool is_packed ATTRIBUTE_UNUSED)
> > > >  {
> > > > -  if (TARGET_VECTOR)
> > > > -    {
> > > > -      if (STRICT_ALIGNMENT)
> > > > -       {
> > > > -         /* Return if movmisalign pattern is not supported for this 
> > > > mode.  */
> > > > -         if (optab_handler (movmisalign_optab, mode) == 
> > > > CODE_FOR_nothing)
> > > > -           return false;
> > > > -
> > > > -         /* Misalignment factor is unknown at compile time.  */
> > > > -         if (misalignment == -1)
> > > > -           return false;
> > > > -       }
> > > > -      return true;
> > > > -    }
> > > > +  /* TODO: For RVV scalable vector auto-vectorization, we should allow
> > > > +     movmisalign<mode> pattern to handle misalign data movement to 
> > > > unblock
> > > > +     possible auto-vectorization.
> > > >
> > > > +     RVV VLS auto-vectorization or SIMD auto-vectorization can be 
> > > > supported here
> > > > +     in the future.  */
> > > >    return default_builtin_support_vector_misalignment (mode, type, 
> > > > misalignment,
> > > >                                                       is_packed);
> > > >  }
> > >
> > > Should we have some corresponding change on autovec.md like this?
> > >
> > > diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
> > > index f1c5ff5951bf..c2873201d82e 100644
> > > --- a/gcc/config/riscv/autovec.md
> > > +++ b/gcc/config/riscv/autovec.md
> > > @@ -51,7 +51,7 @@
> > > (define_expand "movmisalign<mode>"
> > >  [(set (match_operand:V 0 "nonimmediate_operand")
> > >       (match_operand:V 1 "general_operand"))]
> > > -  "TARGET_VECTOR"
> > > +  "TARGET_VECTOR && !STRICT_ALIGNMENT"
> > >  {
> > >    /* Equivalent to a normal move for our purpooses.  */
> > >    emit_move_insn (operands[0], operands[1]);
>

Reply via email to