Re: how to avoid a memset() optimization

Chris F Clark <cfc@shell01.theworld.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.


Tom Payne

Return to the comp.compilers page.
Search the comp.compilers archives again.