> From: Richard Biener <[email protected]> > Sent: Tuesday, November 25, 2025 2:59 PM > > 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. >
Both seem okay to me depending on what we want to check. Let's wait and see. Thx, Haochen
