This is the mail archive of the gcc@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]

Re: Incrementing volatiles?


Jeffrey A Law wrote:
> This is better handled by the standard patterns which can check the
> arguments, and if they are the same produce a 2 operand add.

Ok, I'll have to have a really close look at the i386 rtl generated for
these instructions.  The pa-risc rtl looks ghastly (and optimises as
best as can be expected anyway).

> In general, if you find yourself proposing new RTX codes, or new
> named patterns, then you're probably heading down the wrong path.

Good point, and I accept this point of advice with all seriousness.  I'm
thinking I may have `lost the plot' when Anreas said :

> But that would be an awful special case.  All accesses to a volatile
> variable must be exactly as specified by the user, which means that
> they must never be moved, duplicated or combined.

I took this to mean that insns that refer to a variable must never be
combined, ever.  Now, if they are separate references (ie separate C
expressions(?)) then this restriction makes perfect sense.  However, my
(mis?)understanding of the subject tells me that it would be perfectly
alright (and maybe even desirable) to combine rtx's with in a C level
atomic operation (eg ++) that refers to a volatile variable.  AIUI, one
volatile sequence will never be combined with another sequence (which is
The Right Thing), but nowhere is it stated that instructions *WITHIN* a
volatile sequence cannot be combined.

Also, the statment that volatile accesses cannot be optimised in any way
(you, I think, Jeff), ie the same code must be generated for optimised
and unoptimised generation put me out even more.

The way I see it:

volatile int foo;

int bar()
{
  foo++;
  return foo;
}

Could, with all validity, be compiled as

bar:
    incl  foo
    movl  foo,%eax
    ret

and "return foo++" could be

bar:
    movl  foo,%eax
    incl  foo
    ret

Unless I'm missing something, the volatility of foo is still preserved.

Now, if I'm really off track, can someone please give me some pointers
to information that will set me right?

Bill
-- 
Leave others their otherness


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