This is the mail archive of the 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 22/03/14 01:35, DJ Delorie wrote:
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?

That's not a fair question to ask, since the virtual pass can *only*
use r8-r31.  The first bank has to be left alone else the
devirtualizer becomes a few orders of magnitude harder, if not
impossible, to make work correctly.

What I meant was that because the virtual pass can only use r8-r31, it's causing unnecessary register moves to be generated because it chooses, say, r8 as the register for a byte compare. Because r8 is a *valid* register to use with a byte compare, it sticks with it come what may and then causes additional instructions to be generated to make sure that the result to be compared definitely ends up in r8, even if the register the result was in is also valid for a byte compare operation.

much needless copying, which strengthens my suspicion that it's
something in the RL78 backend that needs 'tweaking'.

Of course it is, I've said that before I think.  The RL78 uses a
virtual model until reload, then converts each virtual instructions
into multiple real instructions, then optimizes the result.  This is

It may be obvious to you and everyone else on this list that it's the backend that needs tweaking but I've only been looking at the compiler internals for a couple of weeks, so unfortunately it's not obvious to me.

I'm not complaining or pointing fingers or anything like that. I'm just trying to understand the reasons why things are the way they are - what things are happening in the backend, what's happening in the 'generic' part and the interactions between them.

I understand that it's easy to say 'This is what the compiler's generating. That's stupid. It should be generating this', which is why I'm trying to understand the reasons that cause the compiler to generate what it's generating.

going to be worse than if the real model had been used throughout
(like arm or x86), but in this case, the real model *can't* be used
throughout, because gcc can't understand it well enough to get through
regalloc and reload.  The RL78 is just to "weird" to be modelled

Can you explain what is too weird about it in particular? It certainly has restrictions on which registers can be used with various instructions but I wouldn't have thought they were that complicated that they couldn't be described using the normal constraints?



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