Re: [ARM][PR65768] Keep constants in register when expanding

[Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>]

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  <kuganv@linaro.org>
> 	    Zhenqiang Chen  <zhenqiang.chen@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  <kuganv@linaro.org>
> 	    Zhenqiang Chen  <zhenqiang.chen@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.