Re: how to avoid a memset() optimization

thp@cs.ucr.edu
24 Nov 2002 01:28:01 -0500

          From comp.compilers

Related articles
[10 earlier articles]
Re: how to avoid a memset() optimization jvorbrueggen@mediasec.de (Jan C. =?iso-8859-1?Q?Vorbr=FCggen?=) (2002-11-13)
Re: how to avoid a memset() optimization usenet-1ugeabe@qeng-ho.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 usenet-1ugeabe@qeng-ho.org (Arthur Chance) (2002-11-15)
Re: how to avoid a memset() optimization joachim_d@gmx.de (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 thp@cs.ucr.edu (2002-11-24)
Re: how to avoid a memset() optimization n1096001003.ch@chch.demon.co.uk (Charles Bryant) (2002-12-01)
| List of all articles for this month |

From: thp@cs.ucr.edu
Newsgroups: comp.compilers
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
Keywords: C, standards
Posted-Date: 24 Nov 2002 01:28:01 EST

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


Post a followup to this message

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