[RL78] Questions about code-generation

Jeff Law law@redhat.com
Sat Mar 22 00:48:00 GMT 2014


On 03/21/14 18:35, DJ Delorie wrote:
>
> I've found that "removing uneeded moves through registers" is
> something gcc does poorly in the post-reload optimizers.  I've written
> my own on some occasions (for rl78 too).  Perhaps this is a good
> starting point to look at?
>
>> 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
> 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
> as-is.
>
> I keep hoping that gcc's own post-reload optimizers would do a better
> job, though.  Combine should be able to combine, for example, the "mov
> r8,ax; cmp r8,#4" types of insns together.
The virtual register file was the only way I could see to make RL78 
work.  I can't recall the details, but when you described the situation 
to me the virtual register file was the only way I could see to make the 
RL78 work in the IRA+reload world.

What would be quite interesting to try would be to continue to use the 
virtualized register set, but instead use the IRA+LRA path.  Presumably 
that wouldn't be terribly hard to try and there's a reasonable chance 
that'll improve the code in a noticeable way.

The next obvious thing to try, and it's probably a lot more work, would 
be to see if IRA+LRA is smart enough (or can be made so with a 
reasonable amount of work) to eliminate the virtual register file 
completely.

Just to be clear, I'm not planning to work on this; my participation and 
interest in the RL78 was limited to providing a few tips to DJ.

Jeff



More information about the Gcc mailing list