On Thu, 25 Nov 2021, Tamar Christina wrote:
>
>
> > -----Original Message-----
> > From: Jakub Jelinek <ja...@redhat.com>
> > Sent: Thursday, November 25, 2021 8:39 AM
> > To: Tamar Christina <tamar.christ...@arm.com>
> > Cc: Richard Biener <rguent...@suse.de>; gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH] match.pd: Fix up the recent bitmask_inv_cst_vector_p
> > simplification [PR103417]
> >
> > On Thu, Nov 25, 2021 at 08:23:50AM +0000, Tamar Christina wrote:
> > > > But, IMNSHO while it isn't incorrect to handle le and gt there, it
> > > > is unnecessary. Because (x & cst) <= 0U and (x & cst) > 0U should
> > > > never appear, again in
> > > > /* Non-equality compare simplifications from fold_binary */ we have
> > > > a simplification for it:
> > > > (if (cmp == LE_EXPR)
> > > > (eq @2 @1))
> > > > (if (cmp == GT_EXPR)
> > > > (ne @2 @1))))
> > > > This is done for
> > > > (cmp (convert?@2 @0) uniform_integer_cst_p@1) and so should be
> > > > done for both integers and vectors.
> > > > As the bitmask_inv_cst_vector_p simplification only handles eq and
> > > > ne for signed types, I think it can be simplified to just following
> > > > patch.
> > >
> > > As I mentioned on the PR I don't think LE and GT should be removed,
> > > the patch Is attempting to simplify the bitmask used because most
> > > vector ISAs can create the simpler mask much easier than the complex
> > mask.
> > >
> > > It. 0xFFFFFF00 is harder to create than 0xFF. So while for scalar it
> > > doesn't
> > matter
> > > as much, it does for vector code.
> >
> > What I'm trying to explain is that you should never see those le or gt cases
> > with TYPE_UNSIGNED (especially when the simplification is moved after
> > those
> > /* Non-equality compare simplifications from fold_binary */ I've
> > mentioned),
> > because if you try:
> > typedef unsigned V __attribute__((vector_size (4)));
> >
> > unsigned f1 (unsigned x) { unsigned z = 0; return x > z; } unsigned f2
> > (unsigned x) { unsigned z = 0; return x <= z; } V f3 (V x) { V z = (V) {};
> > return x >
> > z; } V f4 (V x) { V z = (V) {}; return x <= z; } you'll see that this is at
> > ccp1 when
> > the constants propagate simplified using the rules I mentioned into x !=
> > 0U, x
> > == 0U, x != (V) {} and x == (V) {}.
>
> Ah I see, sorry I didn't see that rule before, you're right that if this is
> ordered
> after it then they can be dropped.
So the patch is OK, possibly with re-ordering the matches.
Thanks,
Richard.
