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.

Reply via email to