[PING][RFC][PATCH] RL78 - Add predicates to reduce code bloat when accessing volatile memory.

Richard Hulme peper03@yahoo.com
Mon May 12 20:03:00 GMT 2014


On 09/05/14 21:20, DJ Delorie wrote:
> The key to the msp430 change is that I reviewed every pattern that
> used the predicates, and only changed the ones where the pattern was
> known to be volatile-safe.  For the RL78, the devirtualizer may make a
> pattern non-volatile-safe, and many patterns are macros which are not
> always volatile-safe.
>
> So, just changing the predicates is probably not enough.  Did you
> review every pattern that used the changed predicates, to ensure that
> they're each volatile safe?

Hi,

Well, I've done my best to confirm that it doesn't break anything.  I've 
looked over the patterns as best I could and looked at the code being 
generated (obviously not every pattern is being used), which didn't show 
anything that seemed wrong, and I've had no issues with running the 
generated code.

My understanding of 'volatile' is that even the resulting code I gave as 
an example is not actually volatile-safe:

mov    a, !240
or    a, #32
mov    !240, a

as the value stored in address 240 could change just before and/or just 
after the 'or', and get overwritten by the second move.

Given that the 'bsf' and 'bcf' instructions (bit set/bit clear) have not 
been included in any patterns, that is as volatile-safe as it can get, 
isn't it?

As I understand it, one of the reasons for having the virtual pass was 
to make the instruction set appear completely orthogonal.  Why then, 
when every instruction can use every virtual register in any addressing 
mode, does it think that:

movw    r10, #240
movw    ax, r10
movw    hl, ax
mov    a, [hl]
or    a, #32
mov    [hl], a

is more volatile-safe?  Unless I'm missing something (which I'm quite 
prepared to accept) it's not less volatile-safe but it's certainly more 
bloated, and makes further optimizations harder.

Richard.



More information about the Gcc-patches mailing list