Re: [RL78] Questions about code-generation

[Oleg Endo <oleg dot endo at t-online dot de>]

On Sun, 2014-03-16 at 19:48 +0100, Richard Hulme wrote:
> On 10/03/14 22:37, DJ Delorie wrote:
> >
> > The use of "volatile" disables many of GCC's optimizations.  I
> > consider this a bug in GCC, but at the moment it needs to be "fixed"
> > in the backends on a case-by-case basis.
> >
> 
> Hi,
> 
> I've looked into the differences between the steps taken when using a 
> variable declared volatile, and when it isn't but I'm getting a bit stuck.
> 
> [...]
>
> Bearing in mind that I'm new to all this and may be missing something 
> blindingly obvious, what would cause 7->8 to fail when declared volatile 
> and not when not?  Does something need adding to rl78-virt.md to allow 
> it to match?
> 
> It doesn't seem like this is due to missing an optimization step that 
> combines insns (hmm, "combine?") but rather to not recognizing that a 
> single, existing insn is possible and so splitting the operation up into 
> multiple steps.

I haven't looked at the details of RL78, but it could be that the memory
constraints refuse to match.  Thus patterns that have mem operands won't
match if the mems are volatile.  This volatile mem check is buried in
the implementation of the 'general_operand' constraint function in
recog.c and is turned on by combine via 'init_recog_no_volatile'.

I ran into a similar issue on SH, where loads/stores from/to volatile
mems with redundant sign/zero extensions wouldn't combine away because
of that volatile mem check in 'general_operand'.  The 'solution' was not
to use 'general_operand' in the SH specific constraints implementation
(e.g. see "general_movsrc_operand" in config/sh/predicates.md).

Maybe this helps.

Cheers,
Oleg