Re: [RL78] Questions about code-generation

[Jeff Law <law at redhat dot com>]

On 03/22/14 05:29, Richard Hulme wrote:
> On 22/03/14 01:47, Jeff Law wrote:
> > 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.
>
> Looking at how that's done by other backends, as far as I can tell, I
> just need to add something like:
>
> #undef  TARGET_LRA_P
> #define TARGET_LRA_P rl78_enable_lra
>
> static bool
> rl78_enable_lra (void)
> {
>    return true;
> }
>
> to rl78.c?  At least in theory, even if other work is needed elsewhere
> to make things run smoothly.
>
> Unfortunately, that function never seems to be called.
>
> How does TARGET_LRA_P get used, anyway?  I can't find anything that
> tries to use it, only places where it gets set.  Is there some funky
> preprocessor stuff going on that's stopping me grepping for it?
That should be enough to switch to the LRA path.   It's a target hook. 
Grep for "targetm.lra_p"


Jeff