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: Volatile MEMs in statement expressions and functions inlined as trees


On Dec 13, 2001, Linus Torvalds <torvalds@transmeta.com> wrote:

> On Thu, 13 Dec 2001, Richard Henderson wrote:
>> On Thu, Dec 13, 2001 at 01:54:11PM -0800, Linus Torvalds wrote:
>> > You misunderstand.
>> >
>> > A plain "p = 0;" assignment does _not_ load anything from memory...
>> 
>> Actually I don't misunderstand.  GCC _will_ do this iff that statement
>> appears in an inlined function.  That is the bug that was originally
>> reported.  I think aoliva has fixed this now, but I can't remember.

> Oh, wow.  Psychedelic.

Yeah.  Handling of statement expressions, used to implement
inlining-as-trees, is a bit, erhm, hackish :-)

>> I'm still stuck on the existence of a sequence point internal to
>> operator= (mentioned by Jason earlier), the fact that the expression
>> is an lvalue, and the fact that reading from p may not yield the 0
>> that was previously stored.

> Yes, reading from "p" may yield something totally different.

> Which is, again, why I point to the oft-quoted sentence, which says that
> the assignment returns the value stored. Which, as you say, is _not_ the
> same as the value we might read back.

I used to think we shouldn't load back in neither C nor C++.  But then
the following thought occurred to me.  Consider:

  (a += b) += c;

If we decide that the rvalue of an assignment needs not be loaded back
from the resulting lvalue, ever, then we can rewrite this as:

  t1 = a;
  t2 = t1 + b;
  a = t2;
  t3 = t2 + c;  // use t2, instead of loading back from a
  a = t3;

Now consider it written like this:

inline volatile int&
pluseq(volatile int &op1, int op2) {
  return op1 += op2;
}

  pluseq(pluseq(a, b), c);


And now, does the pluseq function load from op1 before performing the
addition?  Does it load back afterwards, even though the function
returns a reference?

Clearly, should pluseq be inlined, we'd be able to optimize away the
loading from a in the two cases, but should we?  This would imply that
inlining would change the behavior of the program, by modifying the
load patterns from volatile memory.

Now I'm totally confused as to what the right behavior in C++ should
do, and I'm convinced that lvalue/rvalue distinctions can indeed make
a difference.  I'm not sure they *should* make a difference, but I'm
sure they *can* :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me


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