Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!rbbb.Eng.Sun.COM!chased
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.arch
Subject: Re: What the compiler won't do you for you
Message-ID: <8808@exodus.Eng.Sun.COM>
Date: 28 Feb 91 06:59:36 GMT
References: <8728@exodus.Eng.Sun.COM> <13578:Feb2705:46:4391@kramden.acf.nyu.edu> <8787@exodus.Eng.Sun.COM> <24280:Feb2802:55:4991@kramden.acf.nyu.edu>
Sender: news@exodus.Eng.Sun.COM
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 65


 brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <8787@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
>> Simpler method:
>> compiler writer writes library of inlineable code.
>> compiler writer documents names of routines that are in this library.
>> programmer uses those names.
>
>I give up. The man just refuses to see that this does NOT produce
>portable code. Sun writes one library, and DEC writes another one, and
>Convex writes another one, and a programmer who uses these libraries
>will NOT be able to run his programs on more than one machine.

I believe you forgot to quote the next line that said "if you insist,
provide portable implementations of the subroutines in that library".
Ergo, portable code.  Or, the programmer can write the portable code
him- or herself; that's no harder than your atrocity.  No harder for
programmers, simpler for compiler, easier to maintain, means BETTER.
Furthermore, note that your scheme for triggering special instructions
through the use of special code sequences doesn't do anything for all
the code that has already been written.  No win means not better.

>Nor does he see that the compiler writer NEVER has to make such a
>promise.

If the documentation says "do this to get the compiler to emit the
splartzfooie instruction", that's a promise.  It seems to be the case
that a non-trivial number of people with money will interpret ANY
discovered behavior as a promise, so imagine the signicance of
documentation.

>Actually, David, I found out from e-mail that essentially the same ideas
>have been published before, in many separate papers.

References, please.  I'd love to be enlightened.

>I still find it amazing that David can draw a line between optimizing
>*(p+a) into a single instruction on a Convex, optimizing c = a/b and
>d = a%b into a single instruction on most CISC chips, and optimizing a
>short Hamming weight function into a single instruction on a Cyber.

It's an easy distinction to make.  I'll bet you'd loan someone a dime,
and not be too upset about not getting it back.  I'll also bet that
you wouldn't feel the same way about $100.  Same difference -- LOTS of
code can benefit from recognizing *(p+a), AND it is easy to recognize
using any number of fast algorithms (it is a simple tree pattern, and
no unification is required).  Recognizing that two divisions can be
compressed into one is not so automatic, but it matters sometimes, and
it isn't too hard to catch most cases, given a basic block that's had
value numbers applied to it.  This last case occurs far less often,
and I think it's harder to recognize (I'd have to go look up what a
Hamming weight function is.  If it involves a loop, it is harder).
Given the low return for high investment, why bother?

So, the line is easy to draw:  profitable, probably profitable,
probably unprofitable.  You and Herman Rubin are not a large enough
market to justify more than a couple of minutes of work, especially
given that there is an alternative.  There are far better wild geese
to chase.

[Lest anyone wonders why I persist, I'm practicing for the day when I
have to deal with a two-year old.]

David Chase
Sun