> -----Original Message-----
> From: Richard Biener <rguent...@suse.de>
> Sent: Thursday, December 14, 2023 1:13 PM
> To: Tamar Christina <tamar.christ...@arm.com>
> Cc: Richard Sandiford <richard.sandif...@arm.com>; gcc-patches@gcc.gnu.org;
> nd <n...@arm.com>; j...@ventanamicro.com
> Subject: RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for
> codegen of exit code
>
> On Wed, 13 Dec 2023, Tamar Christina wrote:
>
> > > > > else if (vect_use_mask_type_p (stmt_info))
> > > > > {
> > > > > unsigned int precision = stmt_info->mask_precision;
> > > > > scalar_type = build_nonstandard_integer_type (precision, 1);
> > > > > vectype = get_mask_type_for_scalar_type (vinfo, scalar_type,
> > > > > group_size);
> > > > > if (!vectype)
> > > > > return opt_result::failure_at (stmt, "not vectorized:
> > > > > unsupported"
> > > > > " data-type %T\n",
> > > > > scalar_type);
> > > > >
> > > > > Richard, do you have any advice here? I suppose
> vect_determine_precisions
> > > > > needs to handle the gcond case with bool != 0 somehow and for the
> > > > > extra mask producer we add here we have to emulate what it would have
> > > > > done, right?
> > > >
> > > > How about handling gconds directly in vect_determine_mask_precision?
> > > > In a sense it's not needed, since gconds are always roots, and so we
> > > > could calculate their precision on the fly instead. But handling it in
> > > > vect_determine_mask_precision feels like it should reduce the number
> > > > of special cases.
> > >
> > > Yeah, that sounds worth trying.
> > >
> > > Richard.
> >
> > So here's a respin with this suggestion and the other issues fixed.
> > Note that the testcases still need to be updated with the right stanzas.
> >
> > The patch is much smaller, I still have a small change to
> > vect_get_vector_types_for_stmt in case we get there on a gcond where
> > vect_recog_gcond_pattern couldn't apply due to the target missing an
> > appropriate vectype. The change only gracefully rejects the gcond.
> >
> > Since patterns cannot apply to the same root twice I've had to also do
> > the split of the condition out of the gcond in bitfield lowering.
>
> Bah. Guess we want to fix that (next stage1). Can you please add
> a comment to the split out done in vect_recog_bitfield_ref_pattern?
Done.
>
> > Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu and
> no issues.
> >
> > Ok for master?
>
> OK with the above change.
>
Thanks!
That leaves one patch left. I'll have that for you Tuesday morning. Currently
going over it
to see if I can't clean it up (and usually a day or two helps) more to minimize
respins.
I'll then also send the final testsuite patches.
Thanks for all the reviews!
Cheers,
Tamar
