Re: how to avoid a memset() optimization

"Chris F Clark" <cfc@shell01.TheWorld.com>
20 Nov 2002 15:32:00 -0500

          From comp.compilers

Related articles
[9 earlier articles]
Re: how to avoid a memset() optimization fjh@cs.mu.OZ.AU (Fergus Henderson) (2002-11-13)
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: "Chris F Clark" <cfc@shell01.TheWorld.com>
Newsgroups: comp.compilers
Date: 20 Nov 2002 15:32:00 -0500
Organization: The World Public Access UNIX, Brookline, MA
References: 02-11-030 02-11-069 02-11-084 02-11-092
Keywords: C, optimize, standards
Posted-Date: 20 Nov 2002 15:32:00 EST

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.


I don't know to what extent those instructions were supported at the
high-level language interface (certainly one could stick in inline
assembly to do so), but did the compilers generate memory barriers for
sequence points or around volatile accesses? I would doubt that they
did.


Of course, I also doubt that OM was considered to be part of the ANSI
conforming tool chain for C or FORTRAN anyway, since only certain
specific compiler options settings were listed as being ANSI
conformant, and other combinations did not promiss conformance. (I'm
certain that the optimization level that turned on "whole program"
optimization was not part of the ANSI conformant switches.)


That also brings up the whole question of benchmarksmanship. The
compiler options used in running the benchmarks were not the same ones
used for promising ANSI conformance (nor even the same across all
benchmarks). Then again, neither set of options necessarily matched
the ones typical users would have used to compile their programs
either. On the other hand, if one availed oneself of the benchmark
center, there were engineers that would give some help in tuning ones
application and thus finding the right combination of switches, if one
cared enough.


Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
3 Proctor Street voice : (508) 435-5016
Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)
------------------------------------------------------------------------------



Post a followup to this message

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