[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