Re: [Patch] Testsuite fixes for failures caused by patch for PR 80925 - loop peeling and alignment

[Steve Ellcey <sellcey at cavium dot com>]

I am not sure why this is failing on Solaris/SPARC, do you have the
vector dump file from the test so we can see what it says about the
loop it stopped vectorizing?  I don't have a Solaris/SPARC system here,
I tried to build an 'initial' gcc for sparc-sun-solaris2.11 but I 
could not reproduce the error using that.  I am not sure why.

Steve Ellcey
sellcey@cavium.com

On Fri, 2017-08-04 at 16:27 +0200, Rainer Orth wrote:
> Richard Biener <richard.guenther@gmail.com> writes:
> 
> > 
> > On Fri, Jul 28, 2017 at 8:22 PM, Steve Ellcey <sellcey@cavium.com>
> > wrote:
> > > 
> > > On Fri, 2017-07-28 at 09:47 +0200, Richard Biener wrote:
> > > > 
> > > > On Fri, Jul 28, 2017 at 12:16 AM, Steve Ellcey <sellcey@cavium.
> > > > com> wrote:
> > > > > 
> > > > > 
> > > > > Any comments from the power and/or vectorizer folks?
> > > > On one side I'm inclined to simplify the testsuite by adding
> > > > --param vect-max-peeling-for-alignment=0 in addition to
> > > > -fno-vect-cost-model we already pass and override that in the
> > > > tests that specifically exercise peeling for alignment (do we
> > > > have
> > > > any?).
> > > > OTOH that would remove quite some testing coverage of prologue
> > > > peeling.
> > > > 
> > > > So ideally testresults would be clean with both no such --param
> > > > and that --param added...
> > > > 
> > > > I think most of the testcases you needed to adjust have nothing
> > > > to do with peeling for alignment thus adding this --param just
> > > > for
> > > > those (and simplifying their dump scanning accordingly) is
> > > > another
> > > > pragmatic option.
> > > > 
> > > > Adding yet another target (vect_peel_align) is IMHO not good,
> > > > especially as this one depends on cost tuning and not HW
> > > > features, so it's impossible(?) to dynamically compute it
> > > > with a test compile for example (we _do_ want a clean
> > > > vect.exp with any vector HW / tuning switch you add).
> > > How about something like the following.  I only fixed two of the
> > > tests,
> > > I can follow up with more if this approach seems reasonable.  I
> > > tested
> > > this on aarch64 and x86_64.
> > Looks good to me.
> > 
> > Richard.
> > 
> > > 
> > > Steve Ellcey
> > > sellcey@cavium.com
> > > 
> > > 
> > > 2017-07-28  Steve Ellcey  <sellcey@cavium.com>
> > > 
> > >         PR tree-optimization/80925
> > >         * gcc.dg/vect/no-section-anchors-vect-69.c: Add
> > >         --param vect-max-peeling-for-alignment=0 option.
> > >         Remove unaligned access and peeling checks.
> > >         * gcc.dg/vect/section-anchors-vect-69.c: Ditto.
> This broke the test on Solaris/SPARC:
> 
> +FAIL: gcc.dg/vect/no-section-anchors-vect-69.c scan-tree-dump-times
> vect "vectorized 4 loops" 1
> 
> both 32 and 64-bit.  The dump now has
> 
> no-section-anchors-vect-69.c:39:5: note: vectorized 3 loops in
> function.
> 
> and (compared to the gcc-7 branch)
> 
> no-section-anchors-vect-69.c:44:3: note: not vectorized: unsupported
> unaligned store.tmp1[2].a.n[1][2][i_74]
> 
> 	Rainer
>