On Tue, Nov 25, 2025 at 12:14 AM Kugan Vivekanandarajah <[email protected]> wrote: > > Hi, > > > On 24 Nov 2025, at 9:18 pm, Richard Biener <[email protected]> > > wrote: > > > > External email: Use caution opening links or attachments > > > > > > On Sun, Nov 23, 2025 at 9:21 AM Haochen Jiang <[email protected]> > > wrote: > >> > >> On Linux/x86_64, > >> > >> ed1911b9f1f1ab0c1b631f0b6427b798c7056200 is the first bad commit > >> commit ed1911b9f1f1ab0c1b631f0b6427b798c7056200 > >> Author: Kugan Vivekanandarajah <[email protected]> > >> Date: Sun Nov 23 15:27:10 2025 +1100 > >> > >> [tree-optimization] Allow LICM to hoist loads in "self write" patterns > >> > >> caused > >> > >> FAIL: gcc.dg/vect/bb-slp-41.c -flto -ffat-lto-objects scan-tree-dump-not > >> slp1 "vectorizing stmts using SLP" > >> FAIL: gcc.dg/vect/bb-slp-41.c scan-tree-dump-not slp1 "vectorizing stmts > >> using SLP" > > > > The vectorization done is sensible. The testcase doesn't check was it > > was intended to ... > > we now SLP vectorize the scalar epilog we now unroll. I can't guess > > what we didn't want to > > vectorize (some CTOR, obviously). The testcase was added in > > r10-4336-g818b3293f4545d. > > > > I'll fix the testcase in the most reasonable way > > > > In original 818b3293f454 we had: > +/* See that we vectorize an SLP instance. */ > +/* { dg-final { scan-tree-dump-times "Found vectorizable constructor" 12 > "slp1" } } */ > +/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 4 "slp1" > } } */ > > In commit 3771033244b3ee1b53a8a00d734580b16384fdd3 > Author: Richard Sandiford <[email protected]> > Date: Thu Nov 14 19:24:21 2019 +0000 > > Tweak gcc.dg/vect/bb-slp-4[01].c (PR92366) > gcc.dg/vect/bb-slp-40.c was failing on some targets because the > explicit dg-options overrode things like -maltivec. This patch > uses dg-additional-options instead. > Also, it seems safer not to require exactly 1 instance of each > message, > since that depends on the target vector length. > gcc.dg/vect/bb-slp-41.c contained invariant constructors that are > vectorised on AArch64 (foo) and constructors that aren't (bar). > This meant that the number of times we print "Found vectorizable > constructor" depended on how many vector sizes we try, since we'd > print it for each failed attempt. > In foo, we create invariant { b[0], ... } and { b[1], ... }, > and the test is making sure that the two separate invariant vectors > can be fed from the same vector load at b. This is a different case > from bb-slp-40.c, where the constructors are naturally separate. > (The expected count is 4 rather than 2 because we can vectorise the > epilogue too.) > > > -/* See that we vectorize an SLP instance. */ > -/* { dg-final { scan-tree-dump-times "Found vectorizable constructor" 12 > "slp1" } } */ > -/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 4 "slp1" > } } */ > +/* { dg-final { scan-tree-dump-not "vectorizing stmts using SLP" "slp1" } } > */ > > Later in c9174f2b0378 this becomes > -/* { dg-final { scan-tree-dump-not "vectorizing stmts using SLP" "slp1" } } > */ > +/* { dg-final { scan-tree-dump-not "vectorizable constructor" "slp1" } } */ > > > In essence this is an execution test and hence IMO we should just remove the > scan-tree-dump-not "vectorizable constructor" “slp1”. Any thoughts?
That was another possibility, I have adjusted the scan, let's see if that passes everywhere. Richard. > > Thanks, > Kugan > > >
