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
