On 25/06/2024 12:53, Andre Vieira (lists) wrote: > Hi, > > With the introduction of low overhead loops in > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3dfc28dbbd21b1d708aa40064380ef4c42c994d7 > we defined arm_predict_doloop_p, this is meant to be a low-weight check to > rule out loops we are not considering for doloop optimization and it is used > by other passes to prevent optimizations that may hurt the doloop > optimization later on. The reason these are meant to be lightweight is > because it's used by pre-RTL optimizations, meaning we can't do the same > checks that doloop does. > > After the definition of arm_predict_doloop_p, when testing for > armv8.1-m.main, tree-ssa/ivopts-3.c failed the scan-dump check as the dump > now matched an extra '!= 0' introduced by: > Doloop cmp iv use: if (ivtmp_1 != 0) > Predict loop 1 can perform doloop optimization later. > > where previously we had: > Predict doloop failure due to target specific checks. > > and after this patch: > Predict doloop failure due to call in loop. > Predict doloop failure due to target specific checks. > > Added a copy of the original tree-ssa/ivopts-3.c as a target specifc test to > check for the new dump message. > > Ran a regression test for arm-none-eabi with > -march=armv8.1-m.main+mve/-mfpu=auto/-mthumb/-mfloat-abi=hard. > > OK for trunk? > > gcc/ChangeLog: > > * confir/arm/arm.cc (arm_predict_doloop_p): Reject loops with > function calls that are not builtins. > > gcc/testsuite/ChangeLog: > > * gcc.target/arm/mve/ivopts-3.c: New test.
OK. R.