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?
Thanks,
Kugan
