|[10 earlier articles]|
|Re: how to avoid a memset() optimization email@example.com (Jan C. =?iso-8859-1?Q?Vorbr=FCggen?=) (2002-11-13)|
|Re: how to avoid a memset() optimization firstname.lastname@example.org (Arthur Chance) (2002-11-13)|
|Re: how to avoid a memset() optimization cfc@shell01.TheWorld.com (Chris F Clark) (2002-11-15)|
|Re: how to avoid a memset() optimization email@example.com (Arthur Chance) (2002-11-15)|
|Re: how to avoid a memset() optimization firstname.lastname@example.org (Joachim Durchholz) (2002-11-17)|
|Re: how to avoid a memset() optimization cfc@shell01.TheWorld.com (Chris F Clark) (2002-11-20)|
|Re: how to avoid a memset() optimization email@example.com (2002-11-24)|
|Re: how to avoid a memset() optimization firstname.lastname@example.org (Charles Bryant) (2002-12-01)|
|Date:||24 Nov 2002 01:28:01 -0500|
|Organization:||University of California, Riverside|
|References:||02-11-030 02-11-069 02-11-084 02-11-092 02-11-117|
|Posted-Date:||24 Nov 2002 01:28:01 EST|
Chris F Clark <email@example.com> wrote:
+ Joachim asked:
+> Did these tools honor "volatile" modifiers? I'd assume that for the MIPS
+> compiler suite, but it's hard to imagine that for an OM-style optimizer.
+ John (the moderator) added:
+> Same question for the other sequence point stuff.
+ I don't know for certain, but I doubt it. The MIPS internal
+ representation was based upon a modified P-code (Pascal) compiler and
+ I doubt it had a notation for don't move this across this boundary--at
+ least I don't remember one in the parts of the optimizer I worked on.
+ However, in the OM code, since it was based upon the hardware/OS spec
+ and there was a "memory barrier" instruction, which it was illegal to
+ move memory accesses across. Thus, one could construct programs that
+ had "sequence points" or protect "volatile" locations.
Thanks. I had wondered if practicing compiler writers ever pay
attention to memory barriers. (AFAIK, memory barriers are not needed
for standard C/C++, but they're needed for multithreaded extensions,
e.g., pthreads. Such barriers must prevent instructions from leaking
out the tops and/or bottoms of critical regions. That includes
leakage from code motion by compilers as well as from instruction
rearrangement by hardware.)
It appears that for conforming C/C++ implementations, compiler writers
can ignore sequence points except in the case of
- volatile variables,
- architectures where memory locations are in an inaccessible
state for some time after they've been written.
Apparently, the as-if rule takes care of all other cases.
Return to the
Search the comp.compilers archives again.