On 2026-09-03 12:56, Tamar Christina wrote:
-----Original Message-----
From: Torbjorn SVENSSON <[email protected]>
Sent: 02 September 2026 10:37
To: Richard Biener <[email protected]>
Cc: [email protected]; [email protected]; Richard Earnshaw
<[email protected]>; Tamar Christina <[email protected]>
Subject: Re: [PATCH][v2] Remove -ftree-loop-if-convert, tie tree-if-conv.cc to
vectorization only
On 2026-09-02 11:12, Richard Biener wrote:
On Wed, 2 Sep 2026, Torbjorn SVENSSON wrote:
On 2026-09-01 13:45, Richard Biener wrote:
On Tue, 1 Sep 2026, Torbjorn SVENSSON wrote:
On 2026-09-01 09:39, Richard Biener wrote:
On Mon, 31 Aug 2026, Torbjorn SVENSSON wrote:
Hi,
On 2026-08-28 10:22, Richard Biener wrote:
The following removes the ability to enable stand-alone loop
if-conversion
or to disable loop if-conversion even though vectorization runs. This
was hardly useful before and testing and coverage of this mode is
basically non-existent. Instead phiopt and cselimg are the general
if-conversion vehicles.
This will allow to more tightly integrate vectorizer loop if-conversion
with loop vectorization.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* common.opt (ftree-loop-if-convert): Mark as ignored.
* doc/invoke.texi (ftree-loop-if-convert): Remove.
* tree-ssa-phiopt.cc (cond_if_else_store_replacement):
Do not check !flag_tree_loop_if_convert.
* tree-if-conv.cc (pass_if_conversion::gate): Only
run when loop vectorization is enabled on any loop.
(pass_if_conversion::execute): Adjust.
(tree_if_conversion): Likewise. Simplify as we now
always version.
(convert_scalar_cond_reduction): Remove loop_versioned
argument which is now always true.
(predicate_scalar_phi): Likewise.
(predicate_all_scalar_phis): Likewise.
(combine_blocks): Likewise.
* gcc.dg/vect/bb-slp-pattern-2.c: Adjust.
* gcc.target/i386/pr45685.c: Likewise.
---
gcc/common.opt | 6 +-
gcc/doc/invoke.texi | 12 +-
gcc/testsuite/gcc.dg/vect/bb-slp-pattern-2.c | 4 +-
gcc/testsuite/gcc.target/i386/pr45685.c | 4 +-
gcc/tree-if-conv.cc | 110
+++++++------------
gcc/tree-ssa-phiopt.cc | 6 +-
6 files changed, 50 insertions(+), 92 deletions(-)
...
diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-pattern-2.c
b/gcc/testsuite/gcc.dg/vect/bb-slp-pattern-2.c
index 05fde3a7feb..5f5009b0427 100644
--- a/gcc/testsuite/gcc.dg/vect/bb-slp-pattern-2.c
+++ b/gcc/testsuite/gcc.dg/vect/bb-slp-pattern-2.c
@@ -1,5 +1,5 @@
/* { dg-require-effective-target vect_condition } */
-/* { dg-additional-options "-fno-tree-vectorize -ftree-slp-vectorize
-ftree-loop-if-convert" } */
+/* { dg-additional-options "-fno-tree-vectorize -ftree-slp-vectorize" }
*/
#include "tree-vect.h"
@@ -50,4 +50,4 @@ int main ()
return 0;
}
-/* { dg-final { scan-tree-dump-times "optimized: basic block" 1
"slp1"
{
target { vect_element_align && vect_pack_trunc } } } } */
+/* { dg-final { scan-tree-dump-times "optimized: basic block" 1
"slp1"
{
xfail { vect_element_align && vect_pack_trunc } } } } */
This change now introduces a regression for arm-none-eabi:
Ah, yes. I suppose I'd need both { target { ... } } _and_ XFAIL it.
Not sure if that's possible? Seems dejagnu accepts
/* { dg-final { scan-tree-dump-times "optimized: basic block" 1 "slp1" {
xfail { vect_element_align && vect_pack_trunc } target {
vect_element_align && vect_pack_trunc } } } } */
can you check if that resolves the FAILs?
Unfortunately, I see no difference after changing to the above line.
My gut feeling is telling me that both variants have the same weakness.
In my log, I see this
check_compile tool: gcc for arm_vect_no_misalign
doing compile
Executing on host: /build/r17-3738-gaaa0f6b1e87bc6/bin/arm-none-
eabi-gcc
arm_vect_no_misalign184.c -mthumb -march=armv6s-m -mcpu=cortex-
m0
-mfloat-abi=soft -mfpu=auto -fdiagnostics-plain-output
-Wno-complain-wrong-lang -S -o arm_vect_no_misalign184.s
(timeout =
800)
spawn -ignore SIGHUP /build/r17-3738-gaaa0f6b1e87bc6/bin/arm-
none-eabi-gcc
arm_vect_no_misalign184.c -mthumb -march=armv6s-m -mcpu=cortex-
m0
-mfloat-abi=soft -mfpu=auto -fdiagnostics-plain-output
-Wno-complain-wrong-lang -S -o arm_vect_no_misalign184.s
pid is 2420 -2420
pid is -1
output is status 0
I think that proves my analysis that both the target and the xfail
expressions are evaluated as armv6s-m and not armv7-m+simd and
thus,
will not work properly.
Since we try to cache the evaluated result for all the conditions, I
think this will be hard to implement the right way. The cached result
would be for the armv6s-m target that the entire testsuite is executed
for. The current context in this test is armv7-m+simd, but it is
incompatible with the cached result.
Hmm, but that would be a problem that should show up in way more
cases?
But the error I introduced was to make the conditional PASS
a conditional XFAIL -- I wanted to XFAIL only for where it was
previously enabled to require a PASS. Still I'm not sure whether
{ xfail { vect_element_align && vect_pack_trunc }
target { vect_element_align && vect_pack_trunc } }
will really achieve that - guard the scan-tree-dump-times
on target vect_element_align && vect_pack_trunc and at the
same time xfail it (for the same set of targets).
I can see that there are other tests that have
/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 4
"vect" { target { vect_element_align } xfail { ! vect_unaligned_possible } } }
} */
So I think a combination is possible.
I see. I'll push such a fix then (even if it does not fix your issue).
I suppose the expression could even be simplified to
{ target { vect_element_align && vect_pack_trunc } xfail *-*-* }
based on that there are examples like:
/* { dg-final { scan-tree-dump "Built SLP cancelled: can use load/store-lanes"
"vect" { target { vect_perm3_int && vect_load_lanes } xfail *-*-* } } } */
Maybe the proper fix for this issue is to address
check_vect_support_and_set_flags
instead. What if we change from [is-effective-target arm_neon_ok] to
something
that does not cause a target change. E.g., only run vect.exp tests when
the selected target supports neon.
Would this be a better solution?
Not sure. Tamar recently dived into caching issues, so maybe he has
an idea as well.
Yeah I guess the problem is that the changes to the flags the vect testsuite
adds doesn't get added to the target specific flags. As such the cache
incorrectly
enabled/disables a guard.
I fear though that you can't fix it in check_vect_support_and_set_flags because
it's not directly in charge of the cache key creation.
Could you see if my prototype patch fixes this
https://inbox.sourceware.org/gcc-patches/vi0pr08mb10392913fc10b3b4d5a8aca12ff...@vi0pr08mb10392.eurprd08.prod.outlook.com/T/#m1c1b86a12f06965818f10a0c6e1ad2623a213532
I took this for a test run over night and there are still issues left to be
sorted.
For an arm-none-eabi run with
thumb/arch=armv6s-m/cpu=cortex-m0/float-abi=soft/fpu=auto,
I see 553 new fails and 6 less xpass.
I used r17-3738-gaaa0f6b1e87bc6 as a reference, and with that version I get:
Testing vect/O3-pr70130.c
doing compile
Executing on host: /build/r17-3738-gaaa0f6b1e87bc6/bin/arm-none-eabi-gcc
/build/gcc_src/gcc/testsuite/gcc.dg/vect/O3-pr70130.c -mthumb -march=armv6s-m
-mcpu=cortex-m0 -mfloat-abi=soft -mfpu=auto -fdiagnostics-plain-output
-mfloat-abi=softfp -mcpu=unset -march=armv7-a+simd -mfpu=auto -ffast-math
-ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model
-fno-common -O2 -fdump-tree-vect-details -O3 -fno-ipa-cp-clone -S -o
O3-pr70130.s (timeout = 800)
spawn -ignore SIGHUP /build/r17-3738-gaaa0f6b1e87bc6/bin/arm-none-eabi-gcc
/build/gcc_src/gcc/testsuite/gcc.dg/vect/O3-pr70130.c -mthumb -march=armv6s-m
-mcpu=cortex-m0 -mfloat-abi=soft -mfpu=auto -fdiagnostics-plain-output
-mfloat-abi=softfp -mcpu=unset -march=armv7-a+simd -mfpu=auto -ffast-math
-ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model
-fno-common -O2 -fdump-tree-vect-details -O3 -fno-ipa-cp-clone -S -o
O3-pr70130.s
pid is 3525688 -3525688
pid is -1
output is status 0
PASS: gcc.dg/vect/O3-pr70130.c (test for excess errors)
With the patch added on top, I instead get:
Testing vect/O3-pr70130.c
doing compile
Executing on host: /build/r17-3738-gaaa0f6b1e87bc6/bin/arm-none-eabi-gcc
/build/gcc_src/gcc/testsuite/gcc.dg/vect/O3-pr70130.c -mthumb -march=armv6s-m
-mcpu=cortex-m0 -mfloat-abi=soft -mfpu=auto -fdiagnostics-plain-output
-ffast-math -ftree-vectorize -fno-tree-loop-distribute-patterns
-fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -O3
-fno-ipa-cp-clone -S -o O3-pr70130.s (timeout = 800)
spawn -ignore SIGHUP /build/r17-3738-gaaa0f6b1e87bc6/bin/arm-none-eabi-gcc
/build/gcc_src/gcc/testsuite/gcc.dg/vect/O3-pr70130.c -mthumb -march=armv6s-m
-mcpu=cortex-m0 -mfloat-abi=soft -mfpu=auto -fdiagnostics-plain-output
-ffast-math -ftree-vectorize -fno-tree-loop-distribute-patterns
-fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -O3
-fno-ipa-cp-clone -S -o O3-pr70130.s
pid is 3547885 -3547885
In file included from /build/gcc_src/gcc/testsuite/gcc.dg/vect/O3-pr70130.c:5:
/build/gcc_src/gcc/testsuite/gcc.dg/vect/tree-vect.h: In function 'check_vect':
/build/gcc_src/gcc/testsuite/gcc.dg/vect/tree-vect.h:71:5: error: impossible
constraint in 'asm'
pid is -1
close result is 3547885 exp7 0 1
output is In file included from
/build/gcc_src/gcc/testsuite/gcc.dg/vect/O3-pr70130.c:5:
/build/gcc_src/gcc/testsuite/gcc.dg/vect/tree-vect.h: In function 'check_vect':
/build/gcc_src/gcc/testsuite/gcc.dg/vect/tree-vect.h:71:5: error: impossible
constraint in 'asm'
status 1
compiler exited with status 1
FAIL: gcc.dg/vect/O3-pr70130.c (test for excess errors)
Excess errors:
/build/gcc_src/gcc/testsuite/gcc.dg/vect/tree-vect.h:71:5: error: impossible
constraint in 'asm'
So, it looks like the "-mfloat-abi=softfp -mcpu=unset -march=armv7-a+simd
-mfpu=auto"
flags where lost somewhere.
Please let me know when you have a nother revision of the patch that you would
like
me to test.
Kind regards,
Torbjörn
I'm busy cleaning this up to submit. But essentially we treat the torture
flags as
new cache key elements and make the vectorizer flags a torture option.
Thanks,
Tamar
Thanks.
Torbjörn
Richard.
Kind regards,
Torbjörn
Richard.
Kind regards,
Torbjörn
Thanks,
Richard.
Testing vect/bb-slp-pattern-2.c
doing compile
Executing on host: /build/r17-3730-g33495b439916fe/bin/arm-
none-eabi-gcc
/build/gcc_src/gcc/testsuite/gcc.dg/vect/bb-slp-pattern-2.c -mthumb
-march=armv6s-m -mcpu=cortex-m0 -mfloat-abi=soft -mfpu=auto
-fdiagnostics-plain-output -mfloat-abi=softfp -mcpu=unset
-march=armv7-a+simd -mfpu=auto -ffast-math -ftree-vectorize
-fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common
-O2
-fdump-tree-slp-details -fno-tree-vectorize -ftree-slp-vectorize -S
-o
bb-slp-pattern-2.s (timeout = 800)
spawn -ignore SIGHUP
/build/r17-3730-g33495b439916fe/bin/arm-none-eabi-gcc
/build/gcc_src/gcc/testsuite/gcc.dg/vect/bb-slp-pattern-2.c -mthumb
-march=armv6s-m -mcpu=cortex-m0 -mfloat-abi=soft -mfpu=auto
-fdiagnostics-plain-output -mfloat-abi=softfp -mcpu=unset
-march=armv7-a+simd
-mfpu=auto -ffast-math -ftree-vectorize
-fno-tree-loop-distribute-patterns
-fno-vect-cost-model -fno-common -O2 -fdump-tree-slp-details
-fno-tree-vectorize -ftree-slp-vectorize -S -o bb-slp-pattern-2.s
pid is 2927683 -2927683
pid is -1
output is status 0
PASS: gcc.dg/vect/bb-slp-pattern-2.c (test for excess errors)
gcc.dg/vect/bb-slp-pattern-2.c: pattern found 0 times
FAIL: gcc.dg/vect/bb-slp-pattern-2.c scan-tree-dump-times slp1
"optimized:
basic block" 1
In vect.exp, the function check_vect_support_and_set_flags is called.
For
arm-none-eabi, the "arm_neon_ok" is checked and, in my case, returns
success.
As a result, "-mfloat-abi=softfp -mcpu=unset -march=armv7-a+simd
-mfpu=auto"
is appended to DEFAULT_VECTCFLAGS. This causes the test to be
executed
with
the correct target, but the condition for scan-tree-dump-times is
evaluated
in the context of armv6s-m, not armv7-a+simd.
Any idea how to correct this?
Note, I do not see the same failure for other Cortex-M targets that I
test,
only armv6s-m reports it.
Kind regards,
Torbjörn
