On Fri, Oct 15, 2021 at 11:37 PM Martin Sebor <mse...@gmail.com> wrote:
>
> On 10/14/21 1:11 AM, liuhongt wrote:
> > Hi Kewen:
> > Cound you help to verify if this patch fix those regressions
> > for rs6000 port.
> >
> > As discussed in [1], this patch add xfail/target selector to those
> > testcases, also make a copy of them so that they can be tested w/o
> > vectorization.
>
> Just to make sure I understand what's happening with the tests:
> the new -N-novec.c tests consist of just the casses xfailed due
> to vectorizartion in the corresponding -N.c tests? Or are there
Wstringop-overflow-2-novec.c is the same as Wstringop-overflow-2.c
before O2 vectorization adjustment.
Do you want me to reduce them to only contain cases for new xfail/target?
> some other differences (e.g., new cases in them, etc.)? I'd
> hope to eventually remove the -novec.c tests once all warnings
> behave as expected with vectorization as without it (maybe
> keeping just one case both ways as a sanity check).
>
> For the target-supports selectors, I confess I don't know enough
> about vectorization to find their names quite intuitive enough
> to know when to use each. For instance, for vect_slp_v4qi_store:
It's 4-byte char stores with address being 4-bytes aligned.
.i.e.
>
> +# Return the true if target support vectorization of v4qi store.
> +proc check_effective_target_vect_slp_v4qi_store { } {
> + set pattern {add new stmt: MEM <vector\(4\) char>}
> + return [expr { [check_vect_slp_vnqihi_store_usage $pattern ] != 0 }]
> +}
>
> When should this selector be used? In cases involving 4-byte
> char stores? Only naturally aligned 4-bytes stores (i.e., on
> a 4 byte boundary, as the check_vect_slp_vnqihi_store_usage
> suggests?) Or 4-byte stores of any types (e.g., four chars
> as well as two 16-bit shorts), etc.?
>
> Hopefully once all the warnings handle vectorization we won't
> need to use them, but until then it would be good to document
> this in more detail in the .exp file.
>
> Finally, thank you for adding comments to the xfailed tests
> referencing the corresponding bugs! Can you please mention
> the PR in the comment in each of the new xfails? Like so:
>
> index 7d29b5f48c7..cb687c69324 100644
> --- a/gcc/testsuite/c-c++-common/Wstringop-overflow-2.c
> +++ b/gcc/testsuite/c-c++-common/Wstringop-overflow-2.c
> @@ -189,8 +189,9 @@ void ga1__ (void)
>
> struct A1 a = { 1 };
> a.a[0] = 0;
> + // O2 vectorization regress Wstringop-overflow case (1), refer to
> pr102462.
> a.a[1] = 1; // { dg-warning
> "\\\[-Wstringop-overflow" }
> - a.a[2] = 2; // { dg-warning
> "\\\[-Wstringop-overflow" "" { xfail { i?86-*-* x86_64-*-* } } }
> + a.a[2] = 2; // { dg-warning
> "\\\[-Wstringop-overflow" "pr102462" { xfail { vect_slp_v2qi_store } } }
> ^^^^^^^^
> PR in dg-warning comment.
>
> This should make it easier to deal with the XFAILs once
> the warnings have improved to handle vectorization.
Will do.
>
> Martin
--
BR,
Hongtao
