public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Michael Collison <collison@rivosinc.com>,  gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] vect: Check that vector factor is a compile-time constant
Date: Mon, 27 Feb 2023 14:51:18 +0000	[thread overview]
Message-ID: <mpty1ojrwk9.fsf@arm.com> (raw)
In-Reply-To: <CAFiYyc1VpMCFhafvZqL8mQvXMXW68bCMczJVvHBFuOSCEoRqHw@mail.gmail.com> (Richard Biener's message of "Wed, 22 Feb 2023 09:20:13 +0100")

FWIW, this patch looks good to me.  I'd argue it's a regression fix
of kinds, in that the current code was correct before variable VF and
became incorrect after variable VF.  It might be possible to trigger
the problem on SVE too, with a sufficiently convoluted test case.
(Haven't tried though.)

Richard Biener <richard.guenther@gmail.com> writes:
> On Wed, Feb 22, 2023 at 12:03 AM Michael Collison <collison@rivosinc.com> wrote:
>>
>> While working on autovectorizing for the RISCV port I encountered an
>> issue where vect_do_peeling assumes that the vectorization factor is a
>> compile-time constant. The vectorization is not a compile-time constant
>> on RISCV.
>>
>> Tested on RISCV and x86_64-linux-gnu. Okay?
>
> I wonder how you arrive at prologue peeling with a non-constant VF?

Not sure about the RVV case, but I think it makes sense in principle.
E.g. if some ISA takes the LOAD_LEN rather than fully-predicated
approach, it can't easily use the first iteration of the vector loop
to do peeling for alignment.  (At least, the IV steps would then
no longer match VF for all iterations.)  I guess it could use a
*different* vector loop, but we don't support that yet.

There are also some corner cases for which we still don't support
predicated loops and instead fall back on an unpredicated VLA loop
followed by a scalar epilogue.  Peeling for alignment would then
require a scalar prologue too.

> In any case it would probably be better to use constant_lower_bound (vf)
> here?  Also it looks wrong to apply this limit in case we are using
> a fully masked main vector loop.  But as said, the specific case of
> non-constant VF and prologue peeling probably wasn't supposed to happen,
> instead the prologue usually is applied via an offset to a fully masked loop?

Hmm, yeah, agree constant_lower_bound should work too.

Thanks,
Richard

> Richard?
>
> Thanks,
> Richard.
>
>> Michael
>>
>> gcc/
>>
>>      * tree-vect-loop-manip.cc (vect_do_peeling): Verify
>>      that vectorization factor is a compile-time constant.
>>
>> ---
>>   gcc/tree-vect-loop-manip.cc | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-manip.cc
>> index 6aa3d2ed0bf..1ad1961c788 100644
>> --- a/gcc/tree-vect-loop-manip.cc
>> +++ b/gcc/tree-vect-loop-manip.cc
>> @@ -2930,7 +2930,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
>> niters, tree nitersm1,
>>         niters = vect_build_loop_niters (loop_vinfo, &new_var_p);
>>         /* It's guaranteed that vector loop bound before vectorization is at
>>        least VF, so set range information for newly generated var. */
>> -      if (new_var_p)
>> +      if (new_var_p && vf.is_constant ())
>>       {
>>         value_range vr (type,
>>                 wi::to_wide (build_int_cst (type, vf)),
>> --
>> 2.34.1
>>

  parent reply	other threads:[~2023-02-27 14:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-21 23:02 Michael Collison
2023-02-22  8:20 ` Richard Biener
2023-02-22 16:42   ` Michael Collison
2023-02-23  9:08     ` Richard Biener
2023-02-27 14:51   ` Richard Sandiford [this message]
2023-03-01 21:00     ` Michael Collison
2023-03-02  7:56       ` Richard Biener
2023-02-22 15:27 juzhe.zhong
2023-02-22 17:54 ` Michael Collison
2023-02-23  4:01   ` Jeff Law
2023-02-23  4:50     ` Michael Collison
2023-02-24  3:34       ` Jeff Law
2023-02-24  4:04         ` Kito Cheng
2023-03-14 17:48           ` Jeff Law
2023-03-17 16:57             ` Palmer Dabbelt
2023-03-17 16:57               ` Palmer Dabbelt
2023-03-23 23:18               ` Jeff Law
2023-03-24  2:28                 ` Palmer Dabbelt
2023-03-25 22:45                   ` Jeff Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=mpty1ojrwk9.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=collison@rivosinc.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).