[Bug target/42895] Low registers are preferred than register ip in thumb2 mode

[carrot at google dot com]

------- Comment #4 from carrot at google dot com  2010-01-29 19:42 -------
(In reply to comment #3)
> See arm.c:#define REG_ALLOC_ORDER. Comment before it says: " It is good to use
> ip since no saving is required (though calls clobber it) and it never contains
> function parameters. It is quite good to use lr since other calls may clobber
> it anyway."
> 
> So in REG_ALLOC_ORDER, ip (reg 12) and lr (reg 14) come before before r4-r7:
> 
> #define REG_ALLOC_ORDER                         \
> {                                               \
>      3,  2,  1,  0, 12, 14,  4,  5,             \
>      6,  7,  8, 10,  9, 11, 13, 15,             \
>     16, 17, 18, 19, 20, 21, 22, 23,             \
>     27, 28, 29, 30, 31, 32, 33, 34,             \
>     35, 36, 37, 38, 39, 40, 41, 42,             \
>     43, 44, 45, 46, 47, 48, 49, 50,             \
>     51, 52, 53, 54, 55, 56, 57, 58,             \
>     59, 60, 61, 62,                             \
>     24, 25, 26,                                 \
> 
> So the register allocator faithfully does what the IBTK has asked it to :-)
> 

When I set the option -march=armv5te, gcc can generate the expected result, use
r6 and r7 instead of ip. Then I noticed the function
arm_order_regs_for_local_alloc which over writes the default REG_ALLOC_ORDER
with

/* Order of allocation of core registers for Thumb: this allocation is
   written over the corresponding initial entries of the array
   initialized with REG_ALLOC_ORDER.  We allocate all low registers
   first.  Saving and restoring a low register is usually cheaper than
   using a call-clobbered high register.  */

static const int thumb_core_reg_alloc_order[] =
{
   3,  2,  1,  0,  4,  5,  6,  7,
  14, 12,  8,  9, 10, 11, 13, 15
};

But the confusion part is:

1. It rewrites the order when the target is TARGET_THUMB, it should also impact
THUMB2.
2. When I set a breakpoint to arm_order_regs_for_local_alloc and try to find
when the order is changed, the breakpoint is never triggered, even with option
-march=armv5te.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42895