On Fri, Nov 17, 2023 at 8:20 PM Robin Dapp wrote:
>
> > No, you shouldn't place _7 != 0 inside the .COND_ADD but instead
> > have an extra pattern stmt producing that so
> >
> > patt_8 = _7 != 0;
> > patt_9 = .COND_ADD (patt_8, ...);
> >
> > that's probably still not enough, but I always quickly
> No, you shouldn't place _7 != 0 inside the .COND_ADD but instead
> have an extra pattern stmt producing that so
>
> patt_8 = _7 != 0;
> patt_9 = .COND_ADD (patt_8, ...);
>
> that's probably still not enough, but I always quickly forget how
> bool patterns work ... basically a comparison like
> Yes, your version is also OK.
The attached was bootstrapped and regtested on aarch64, x86 and
regtested on riscv. Going to commit it later unless somebody objects.
Regards
Robin
Subject: [PATCH] vect: Pass truth type to vect_get_vec_defs.
For conditional operations the mask is loop
On Fri, Nov 17, 2023 at 9:45 AM Robin Dapp wrote:
>
> > But note you can explicitly specify a vector type as well, there's an
> > overload for it, so we can fix the "invariant" case with the following
> > (OK if you can test this on relevant targets)
> >
> > diff --git a/gcc/tree-vect-loop.cc
> But note you can explicitly specify a vector type as well, there's an
> overload for it, so we can fix the "invariant" case with the following
> (OK if you can test this on relevant targets)
>
> diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
> index 3f59139cb01..936a3de9534 100644
>
On Thu, Nov 16, 2023 at 11:30 PM Robin Dapp wrote:
>
> > For the fortran testcase we don't even run into this but hit an
> > internal def and assert on
> >
> > gcc_assert (STMT_VINFO_VEC_STMTS (def_stmt_info).length () ==
> > ncopies);
> >
> > I think this shows missing handling of .COND_*
> For the fortran testcase we don't even run into this but hit an
> internal def and assert on
>
> gcc_assert (STMT_VINFO_VEC_STMTS (def_stmt_info).length () == ncopies);
>
> I think this shows missing handling of .COND_* in the bool pattern recognition
> as we get the 'bool' condition as
On Wed, Nov 8, 2023 at 5:18 PM Robin Dapp wrote:
>
> Hi,
>
> as Tamar reported in PR112406 we still ICE on aarch64 in SPEC2017
> when creating COND_OPs in ifcvt.
>
> The problem is that we fail to deduce the mask's type from the statement
> vectype and then end up with a non-matching mask in
Hi,
as Tamar reported in PR112406 we still ICE on aarch64 in SPEC2017
when creating COND_OPs in ifcvt.
The problem is that we fail to deduce the mask's type from the statement
vectype and then end up with a non-matching mask in expand. This patch
checks if the current op is equal to the mask
