Re: Safety and legality of optimizations

cliffc@crocus.hpl.hp.com (Cliff Click)
Mon, 3 Apr 1995 15:08:38 GMT

          From comp.compilers

Related articles
Re: Optimizing Across && And || bart@cs.uoregon.edu (1995-02-23)
Re: Safety and legality of optimizations cliffc@crocus.hpl.hp.com (1995-03-21)
Re: Safety and legality of optimizations Vinod.Grover@Eng.Sun.COM (1995-03-28)
Re: Safety and legality of optimizations cliffc@crocus.hpl.hp.com (1995-04-03)
Re: Safety and legality of optimizations cef@geodesic.com (Charles Fiterman) (1995-04-15)
Re: Safety and legality of optimizations Dave@OCCL-CAM.DEMON.CO.UK (Dave Lloyd) (1995-04-18)
Re: Safety and legality of optimizations cliffc@crocus.hpl.hp.com (1995-04-17)
Re: Safety and legality of optimizations jim@meiko.co.uk (1995-04-21)
Re: Safety and legality of optimizations clodius@lanl.gov (1995-04-26)
| List of all articles for this month |

Newsgroups: comp.compilers
From: cliffc@crocus.hpl.hp.com (Cliff Click)
Keywords: optimize, design
Organization: Hewlett-Packard Laboratories, Cambridge Research Office
References: 95-02-179 95-04-018
Date: Mon, 3 Apr 1995 15:08:38 GMT

Vinod.Grover@Eng.Sun.COM (Vinod Grover) writes:


> Cliff Click <cliffc@crocus.hpl.hp.com> wrote:
> >Moving I/O across a potentially infinite loop is bad.
> >However, you _can_ move everything else across the loop, as long as you
> >preserve all data- & control- dependences. You can even move other
> >potentially infinite loops across.


> This is not quite true, especially in certain system applications
> where multiple threads or processes might be active. A typical case is
> when spinlocks/busy-waits are used for implementing critical sections.
> A critical section may contain non-I/O statements that manipulate a
> shared data structure, e.g. a bounded buffer. The lock-variable
> itself might be declared as volatile, but not necessarily the data
> structure being manipulated in the critical section:




I would claim shared data has volatile-like behavior. It can change
"unpredictably" behind the compiler's back, and thus has to be
flagged as volatile. This probably leads to unacceptable
performance. I think the problem lies with "volatile" - it's too
strong for threads (but just right for hardware interrupts). (I put
"unpredictably" in quotes because it's perfectly predictable, but C
has no way to tell the compiler the necessary information!).


Given the popularity of threads, it might make sense to champion a
"shared" keyword - something between volatile and nothing - but I
have no idea what! Of course, the parallel-language guys have been
at it awhile.


Can some kind netter post a summary of the popular paradigms for
shared structures and mutual exclusion _extensions_to_ languages_?
Or has the parallel-language community given up on C? :-)


Cliff
--
Cliff Click Compiler Research Scientist
Cambridge Research Office, Hewlett-Packard Laboratories
One Main Street, 10th Floor, Cambridge, MA 02142
(617) 225-4915 Work (617) 225-4930 Fax
cliffc@hpl.hp.com http://bellona.cs.rice.edu/MSCP/cliff.html
--


Post a followup to this message

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