On 15/04/15 08:48, Kugan wrote: > As mentioned in PR65768, ARM gcc generates suboptimal code for constant > Uses in loop. Part of the reason is that ARM back-end is splitting > constants during expansion of RTL, making it hard for the RTL > optimization passes to optimize it. Zhenqiang posted a patch at > https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00325.html to fix this > > As mentioned in PR65768, I tried with few more test-cases and enhanced > it. Regression tested on arm-none-linux-gnu and no new regressions. Is > this OK for trunk? > > Thanks, > Kugan > > > gcc/ChangeLog: > > 2015-04-15 Kugan Vivekanandarajah <kug...@linaro.org> > Zhenqiang Chen <zhenqiang.c...@linaro.org> > > PR target/65768 > * config/arm/arm-protos.h (const_ok_for_split): New definition. > * config/arm/arm.c (const_ok_for_split): New function. > * config/arm/arm.md (subsi3, andsi3, iorsi3, xorsi3, movsi): Keep some > large constants in register instead of splitting them. > > gcc/testsuite/ChangeLog: > > 2015-04-15 Kugan Vivekanandarajah <kug...@linaro.org> > Zhenqiang Chen <zhenqiang.c...@linaro.org> > > PR target/65768 > * gcc.target/arm/maskdata.c: New test. >
While I support your goals, I think your approach needs some refinement. In particular, we DO NOT want another function that starts looking at constant values and tries to decide, on a case by case basis, what to do with that value. We need to keep the logic for that, as much as possible, in one small set of functions so that the compiler cannot end up with conflicting decisions coming from different bits of code. So const_ok_for_split has to go. Instead you should be using const_ok_for op (an existing routine) and a simple macro that encapsulates "optimize >= 2 && can_create_pseudo_p ()" as the gate for when to use a separate scratch register. R.
