Path: utzoo!mnetor!uunet!husc6!umix!umich!mibte!gamma!pyuxp!pyuxe!pyuxf!robf2
From: robf2@pyuxf.UUCP (robert fair)
Newsgroups: comp.lang.c
Subject: Re: (So-Called) ANSI C
Message-ID: <203@pyuxf.UUCP>
Date: 22 Dec 87 15:17:55 GMT
References: <4668@pyr.gatech.EDU> <3873@uw-june.UUCP>
Organization: Bell Communications Research
Lines: 56
Summary: #pragma != noalias

> This is why I think pragmas are a better mechanism for doing things like
> ``noalias'', etc.  I'm now a little bothered that the debate over whether
> to have ``noalias'' rages on yet nobody has talked about leaving the
> language alone and using pragmas to get the optimizations...
> 
> 	;-D on  (The San Francisco Treat)  Pardo

MSC 5.0 has exactly these kind of pragmas/command line options, and they 
have one  main drawback - they affect ALL variables within the selected 
range, e.g.:

#pragma noalias(on)
func()
{
	char	*c;
	char	*d;
	,,,
}
#pragma noalias(off)

This is inappropriate in cases where only some of the variables in a
function are aliased - its all-or-nothing optimization.

The ``noalias'' keyword allows much finer control of exactly which 
variables have aliases:

func()
{
	        char	*c;
	noalias char	*d;
}

One alterative is to allow the pragma to specify the name of the variable
being noaliaised (MSC does things like this for inline-code generation):

#pragma inline(memcpy)

#pragma noalias(d)
func()
{
	char	*c;
	char	*d;
	,,,
}

It seems that this has some serious problems in implementation,
for example how far should the aliasing information be rememebered,
(single function, rest of the source file etc)
and how should variables redefined in nested scope be handled ?


Robf Fair
Bellcore/CHC
ihnp4!pyuxww!pyuxf!robf2

Generic Disclaimer Applies - Opinions expressed here are mine alone.