This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RL78] Questions about code-generation


On 11/03/14 01:40, DJ Delorie wrote:
I'm curious.  Have you tried out other approaches before you decided
to go with the virtual registers?

Yes.  Getting GCC to understand the "unusual" addressing modes the
RL78 uses was too much for the register allocator to handle.  Even
when the addressing modes are limited to "usual" ones, GCC doesn't
have a good way to do regalloc and reload when there are limits on
what registers you can use in an address expression, and it's worse
when there are dependencies between operands, or limited numbers of
address registers.

Is it possible that the virtual pass causes inefficiencies in some cases by sticking with r8-r31 when one of the 'normal' registers would be better?

For example, I'm having a devil of a time convincing the compiler that an immediate value can be stored directly in any of the normal 16-bit registers (e.g. 'movw hl, #123'). I'm beginning to wonder whether it's the unoptimized code being fed in that's causing problems.

Taking a slight variation on my original test code (removing the 'volatile' keyword and accessing an 8-bit memory location):

--------

#define SOE0L (*(unsigned char *)0xF012A)

void orTest()
{
   SOE0L |= 3;
}

--------

produces (with -O0)

  28                                    _test:
  29 0000 C9 F0 2A 01                           movw    r8, #298
  30 0004 C9 F2 2A 01                           movw    r10, #298
  31 0008 AD F2                                 movw    ax, r10
  32 000a BD F4                                 movw    r12, ax
  33 000c FA F4                                 movw    hl, r12
  34 000e 8B                                    mov     a, [hl]
  35 000f 9D F2                                 mov     r10, a
  36 0011 6A F2 03                              or      r10, #3
  37 0014 AD F0                                 movw    ax, r8
  38 0016 BD F4                                 movw    r12, ax
  39 0018 DA F4                                 movw    bc, r12
  40 001a 8D F2                                 mov     a, r10
  41 001c 48 00 00                              mov     [bc], a
  42 001f D7                                    ret

In some cases, the normal optimization steps remove a lot, if not all, of the unnecessary register passing, but not always.

The conditions on the movhi_real insn allow an immediate value to be stored in (for example) HL directly, and yet I cannot find a single instance in my project where it isn't in the form of

movw    r8, #298
movw    ax, r10
movw    hl, ax

and no manner of re-arranging the conditions (that I've found) will cause the correct code to be generated. It's determined to put the immediate value into rX, and then copy that into ax (which is also unnecessary).

I see the same problem with 'cmp' when the value to be compared is in the A register:

mov     r8, a
cmp     r8, #3

The A register is the one register that can be almost guaranteed to be usable with any instruction, and copying it to R8 (or wherever) to perform the comparison not only wastes two bytes for the move but also makes the cmp instruction a byte longer, so five bytes are used instead of two.

I looked at the code produced for IA64 and ARM targets, and although I'm not as familiar with those instruction sets, they didn't appear to do as much needless copying, which strengthens my suspicion that it's something in the RL78 backend that needs 'tweaking'.

The suggestions made regarding 'volatile' were very helpful and I've made some good savings elsewhere by adding support for different addressing modes and more efficient instructions but there are still a number of (theoretically) easy pickings that should (I feel) be possible before more complicated optimizations need to be looked at.

As ever, any suggestions are very gratefully received. I hope to be able to post some patches once I'm comfortable that I haven't missed anything obvious or done something stupid.

Regards,

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]