This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]