RE: [PATCH 1/2]middle-end: Support early break/return auto-vectorization.

[Tamar Christina <Tamar.Christina@arm.com>]

> -----Original Message-----
> From: Gcc-patches <gcc-patches-
> bounces+tamar.christina=arm.com@gcc.gnu.org> On Behalf Of Jeff Law via
> Gcc-patches
> Sent: Wednesday, November 2, 2022 10:33 PM
> To: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH 1/2]middle-end: Support early break/return auto-
> vectorization.
> 
> 
> On 11/2/22 15:50, Bernhard Reutner-Fischer via Gcc-patches wrote:
> > On 2 November 2022 15:45:39 CET, Tamar Christina via Gcc-patches <gcc-
> patches@gcc.gnu.org> wrote:
> >> Hi All,
> >>
> >> This patch adds initial support for early break vectorization in GCC.
> >> The support is added for any target that implements a vector cbranch
> optab.
> >>
> >> Concretely the kind of loops supported are of the forms:
> >>
> >> for (int i = 0; i < N; i++)
> >> {
> >>    <statements1>
> >>    if (<condition>)
> >>      <action>;
> >>    <statements2>
> >> }
> >>
> >> where <action> can be:
> >> - break
> >> - return
> > Just curious, but don't we have graphite for splitting loops on control flow,
> respectively reflow loops to help vectorization like in this case? Did you
> compare, and if so, what's missing?
> 
> Graphite isn't generally enabled, is largely unmaintained and often makes
> things worse rather than better.
> 

Indeed, but also couldn't get graphite to do much in this case.

Pass just says

0 loops carried no dependency.
Pass statistics of "graphite": ----------------

And bails out. and none of the other graphite passes seem to put anything
in the dump files..

That aside, other reason to do it in the vectorizer is that eventually we can build
to support general control flow support and vectorizing these loops without
needing to peel the loop for ISAs that are fully masked.

Regards,
Tamar

> 
> jeff
>