Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!milton!ogicse!intelhf!ichips!iwarp.intel.com!inews!hopi!bhoughto
From: bhoughto@hopi.intel.com (Blair P. Houghton)
Newsgroups: comp.lang.c
Subject: Re: low level optimization
Message-ID: <3951@inews.intel.com>
Date: 22 Apr 91 08:42:41 GMT
Article-I.D.: inews.3951
References: <21818@lanl.gov> <3905@inews.intel.com> <22025@lanl.gov>
Sender: news@inews.intel.com
Organization: Intel Corp, Chandler, AZ
Lines: 62

In article <22025@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
[...and forgets to attribute me _again_...]
>> [...]     but why is it so horrible to you to document
>> to the users of your optimized libraries that certain
>> arguments to certain functions must be carefully
>> non-aliased?  [...]
>
>It's not horrible.  You miss my point if you believe that I would
>oppose that.

It's the best solution there is, and you still want
to crock a working language.

>You give me a portable way to declare to the compiler
>that two (or more) arguments are assumed not to be aliased and I will 
>rejoice.

Rejoice away:

	double *array_mollify(double *bar)
	/* Mr. Compiler, I declare that no aliasing is being done and I've put it in the man-page so you can optimize until the whole function is but an opcode */
	{
	    ...
	}

It's as good as any, and you can forget portable.  Your
optimization is dependent on the cpu, the OS, the compiler,
the compiler flags, and the main-memory organization.
At the least.

With all that against it, how bad would it be if it's also
dependent on the source language?  How good would it be
to understand finally that we've been telling the truth
for three days when we say it is most definitely NOT
dependent on the source language?

>The problem is that what people are recommending is _not_ portable
>and is _not_ an explicit declaration (so the end user has to guess 
>which variables the compiler optimized in this way and which are 
>safe to alias).

Are you doing this deliberately?  Nobody has to guess
a thing.  You tell them.  "Argument 1 is safe; when
argument 2 is unaliased and you use the -bletch flag,
the compiler is free to optimize the arrays in the
Fooby way; if you specify -bletch but alias argument 2,
grave danger will befall the system."

On the other hand, it's portable as long as you don't
expect it.  You can't expect it.  Optimization is
irrelevant.  Portability is given.  If I "translate" a
conforming program into sign language and get Koko the
gorilla to perform the correct operations on the data, it's
still ANSI.

				--Blair
				  "Koko knows the way to the
				   Ice cream store, and cried
				   when she was told her kitten
				   had died, but I bet she doesn't
				   do pointer-abalias-dependent
				   optimizations..."