dant@tekla.TEK.COM (Dan Tilque;1893;92-789;LP=A;60aC) (12/17/87)
Doug Gwyn writes: > >The good news is, it appears that the second formal public review of >the draft proposed standard for C may start as early as February. >This time it will last for two months, and we hope that nothing will >turn up that requires more than minor editorial changes for the final >official standard. > >A new keyword, "noalias", was added; it's a type-qualifier like const >and volatile. Its only function is to permit tighter optimization, > >Parenthesis grouping is now honored. The Committee giveth and the Committee taketh away. On the one hand they take away optimization by requiring the parenthesis be honored but then they add a whole new keyword, "noalias", to allow better optimization by compilers. Will they please make up their collective mind. It also seems pretty late in the process to be making major changes like adding keywords. Is there any current compiler (i.e. prior art) which uses 'noalias'? If so, how much better is the code generated by it? Also, how much worse will the code be when paren grouping must be honored? I'm still trying to figure out exactly how to use 'const' and 'volatile'. Of course, I don't have a compiler which will accept them, so the question is moot for now. --- Dan Tilque dant@tekla.tek.com or dant@tekla.UUCP
gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/18/87)
In article <2845@zeus.TEK.COM> dant@tekla.UUCP (Dan Tilque) writes: >It also seems pretty late in the process to be making major changes like >adding keywords. Is there any current compiler (i.e. prior art) which >uses 'noalias'? If so, how much better is the code generated by it? The "noalias" keyword itself is new, but not the particular optimization it permits. The answer to the code efficiency question depends on the particular implementation environment. It can make a drastic difference for some functions with parameters that are pointers to noalias objects. >Also, how much worse will the code be when paren grouping must be honored? I don't think it matters much. If your environment is such that the same result is obtained either way, which is true of many environments, the optimzer can go ahead and rearrange integer expressions at least.
hansen@mips.UUCP (Craig Hansen) (12/18/87)
Doug Gwyn writes (about the last ANSI C standards meeting): >A new keyword, "noalias", was added; it's a type-qualifier like const >and volatile. Its only function is to permit tighter optimization, > >Parenthesis grouping is now honored. I am pleased to hear of the ruling on parenthesis grouping: people will recall the acrimonious treatment the idea received in this newsgroup some time ago, and for good reason. "noalias" appears to be ill-conceived. Pointer aliasing happens _between_ a _pair_ of pointers, and is not a particularly useful property of a single pointer. Fortran 77 actually has this property specified in a different form; that no two procedure parameters may yield references that alias to the same location, and for vector operations, it can be responsible for significant speed-ups. However, checking for its proper use is extremely difficult, and I would conjecture, as difficult as the halting problem. -- Craig Hansen Manager, Architecture Development MIPS Computer Systems, Inc. ...{ames,decwrl,prls}!mips!hansen or hansen@mips.com
gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/19/87)
In article <1174@mips.UUCP> hansen@mips.UUCP (Craig Hansen) writes: >Fortran 77 actually has this property specified in a different form... Which we unfortunately cannot adopt for C, due to existing practice. >However, checking for its proper use is extremely >difficult, and I would conjecture, as difficult as the halting problem. Yes, that seems to be correct. That's why the burden of correctness of usage of "noalias" is left to the programmer rather than the compiler.
rmtodd@uokmax.UUCP (Richard Michael Todd) (12/19/87)
In article <2845@zeus.TEK.COM> dant@tekla.UUCP (Dan Tilque) writes: >It also seems pretty late in the process to be making major changes like >adding keywords. Is there any current compiler (i.e. prior art) which >uses 'noalias'? If so, how much better is the code generated by it? I don't know of any compiler that uses the 'noalias' keyword, but both Aztec and Turbo C for the PC have a command line option to specify this type of 'noalias' optimization for an entire file. For Aztec it's '+a', for Turbo it's '-Z'. As for how well it works, I didn't know offhand, but I just did a little expirementing with Aztec C, compiling some C files both with and without the +a optimization, and running diff on the assembly code output. The files I tried came from MicroEmacs 3.9 (I guess that counts as "real world code" :-) I tested three files in all; the first two showed no difference whatsoever with the optimization on and off. The third file I tried, buffer.c, showed some optimization at various places. For the overly-curious, part of the diff listing between the files is shown below. The part marked with '<' is the no-optimization version, the part marked with '>' is the version with the no-alias optimization turned on. Mostly the optimizations look to be simply the result of the compiler keeping better track of stuff left in registers by previous expressions' code. 1148,1149c1140,1141 < push word ptr blistp_+2 < push word ptr blistp_ --- > push es > push bx 1805,1806c1797,1798 < ^ mov dx,word ptr -2[bp] < mov ax,word ptr -4[bp] --- > ^ mov dx,es > mov ax,bx 1821,1827c1813,1817 < mov ax,es:word ptr 4[bx] < mov dx,es:word ptr 6[bx] < mov cx,es:word ptr 16[bx] < mov bx,es:word ptr 18[bx] < cmp dx,bx < jne $20067 < cmp ax,cx --- > mov cx,es:word ptr 4[bx] > mov bx,es:word ptr 6[bx] > cmp bx,dx > jne $20067 > cmp cx,ax 2073,2074c2063,2064 < ^ mov dx,word ptr -2[bp] < mov ax,word ptr -4[bp] --- > ^ mov dx,es > mov ax,bx 2125,2126c2115,2116 < ^ mov dx,word ptr -2[bp] < mov ax,word ptr -4[bp] --- > ^ mov dx,es > mov ax,bx 2140d2129 < les bx,dword ptr -4[bp] 2144,2155c2133,2140 < ^ les bx,dword ptr -4[bp] < mov es:word ptr 8[bx],00H < ; bp->b_markp = NULL; < ^ les bx,dword ptr -4[bp] < mov es:word ptr 12[bx],00H < mov es:word ptr 10[bx],00H < ; bp->b_marko = 0; < ^ les bx,dword ptr -4[bp] < mov es:word ptr 14[bx],00H < ; bp->b_flag = bflag; < ^ mov al,byte ptr 12[bp] < les bx,dword ptr -4[bp] --- > ^ mov es:word ptr 8[bx],00H > ; bp->b_markp = NULL; > ^ mov es:word ptr 12[bx],00H > mov es:word ptr 10[bx],00H > ; bp->b_marko = 0; > ^ mov es:word ptr 14[bx],00H > ; bp->b_flag = bflag; > ^ mov al,byte ptr 12[bp] 2159,2163c2144,2146 < les bx,dword ptr -4[bp] < mov es:word ptr 23[bx],ax < ; bp->b_nwnd = 0; < ^ les bx,dword ptr -4[bp] < mov es:byte ptr 21[bx],00H --- > mov es:word ptr 23[bx],ax > ; bp->b_nwnd = 0; > ^ mov es:byte ptr 21[bx],00H 2167d2149 < les bx,dword ptr -4[bp] 2174,2176c2156,2158 < mov dx,word ptr -2[bp] < mov ax,word ptr -4[bp] < add ax,25 --- > add bx,25 > mov dx,es > mov ax,bx 2199c2181,2182 < les bx,dword ptr -12[bp] --- > mov es,dx > mov bx,ax 2203,2205c2186,2187 < ^ mov dx,word ptr -10[bp] < mov ax,word ptr -12[bp] < les bx,dword ptr -12[bp] --- > ^ mov dx,es > mov ax,bx ___________________________________________________________________________ Richard Todd USSnail:820 Annie Court,Norman OK 73069 UUCP: {allegra!cbosgd|ihnp4}!occrsh!uokmax!rmtodd
drew@geac.UUCP (Drew Sullivan) (12/22/87)
Why are they adding keywords when there is a mechanism that exists to handle hints to the compiler. I mean what did they add #pragma for. Microsoft C 5.0 has the following pragmas now: alloc_text -- for segment management check_stack -- run time stack checking (this is an intel 8088) functions -- to override intrinsics intrinsic -- and to override functions loop_opt -- controls loop optimizing pack -- controls structure packing same_seg -- more segment managment All the compiler writer has to do is add noalias -- for relaxing the aliasing of pointers. In fact maybe 'register' sould be phased out and #pragmas added for special register usage. -- Drew Sullivan <drew@lethe.uucp> -- -- Drew Sullivan <drew@lethe.uucp>
atbowler@orchid.waterloo.edu (Alan T. Bowler [SDG]) (01/06/88)
In article <6860@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > >>Also, how much worse will the code be when paren grouping must be honored? > >I don't think it matters much. If your environment is such that the >same result is obtained either way, which is true of many environments, >the optimzer can go ahead and rearrange integer expressions at least. If you have an situation where overflows are significant, then the "honour parenthesis" rule forbids the compiler from making even simple optimizations like constant folding. If the result of a macro is something like ((a + 1) -1) then an honour parenthesis rule means the compiler can't optimize this to a simple "a" because it will have different overflow characteristics. Note that this will apply to ALL floating point calculations, and any integer calculations in an environment where there exists a signal request that asks the system to report integer overflows. With the new rule parentheses are being asked to perform 2 distinct actions 1) override the default precedence rules 2) specify the evaluation sequence. I did not particularly care for the unary + kludge since I thought the sequencing function was well enough served by the traditional method of multiple statements. However, it was certainly preferable to the new rule which says I when I add parenthesis to make the line clearly to the human reader, I may be making the generated code worse.
mike@arizona.edu (Mike Coffin) (01/07/88)
I think I've figured this out. The committee decided it wanted to
make this big change to C --- forcing all compilers to honor parens, a
rule that is clearly violated by most existing compilers. Now, they knew
that they'd get a lot of flack for this, since it clearly goes beyond
what they're supposed to do. So, how to proceed? MISDIRECTION! I
can just hear A and B talking about it ...
A> How the hell are we going to sneak this paren thing by??
B> Gosh, I don't know. They'll never let us get away with it...
maybe we should just write a new language.
A> I know! Lets introduce a feature so awful, so ugly, so completely
idiotic, that no one will notice the paren thing.
Then we can toss *it* out and keep the paren idea!
Lets see... hmmm... maybe add a new keyword...no one would like
that...
B> yeah! Make sure it's completely useless, though. Unless it adds
absolutely *nothing* to the expressive power of the language
someone will probably *like* it.
A> Too bad we already have "register", *that* would get 'em excited.
B> It would be good if it were something that the compiler can't
possibly check...something that would cause really devilish bugs.
A> How about something a little *like* "register"...
B> ...or "volatile" --- that had a few of them pissed off!
[two hours and a dozen cups of coffee later...]
A> OK, we'll go with "noalias". *Nobody* will buy that.
I can almost hear the screaming now.
B> OK, but what does it mean?
A> I don't know, but that's the beauty of it, don'cha see!
Now, you go write up a description, but make sure that it's
REAL confusing.
B> OK... I just had this horrible thought: what if "noalias" really
makes it into the language?
A> Naaaah. They're not smart, but they're not *THAT* dumb.
This is gonna work like a charm. No one will even *notice*
the new paren rule.
:->
:->
--
Mike Coffin mike@arizona.edu
Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2,ihnp4}!arizona!mike
Tucson, AZ 85721 (602)621-4252franka@mmintl.UUCP (Frank Adams) (01/13/88)
In article <12211@orchid.waterloo.edu> atbowler@orchid.waterloo.edu (Alan T. Bowler [SDG]) writes: >If you have an situation where overflows are significant, then the >"honour parenthesis" rule forbids the compiler from making even simple >optimizations like constant folding. >If the result of a macro is something like > ((a + 1) -1) >then an honour parenthesis rule means the compiler >can't optimize this to a simple "a" because it will have different >overflow characteristics. In this example, the rule does forbid full optimizing on many machines. (One can still compute (a + 1), and then use a, skipping the subtraction.) However, the more normal sort of case, such as ((a + 2) + 3) can still be optimized on almost all architectures. (There are doubtless exceptions, and I really don't want to hear about them.) I was one of those who did not like changing the language to force parentheses to be honored, but I don't think it's such a bad thing -- certainly better than the monadic +. I still like my idea of using square brackets for parentheses which must be honored. Now that the committee has taken this step, maybe this idea can be revived for parentheses which do *not* have to be honored. Not for this version of the standard, of course, but it seems like a reasonable extension for someone to try. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
richard@aiva.ed.ac.uk (Richard Tobin) (01/21/88)
In article <2648@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >> ((a + 1) -1) > >In this example, the rule does forbid full optimizing on many machines. >(One can still compute (a + 1), and then use a, skipping the subtraction.) What overflow behaviour does optimization have to preserve? Presumably the standard does not specify behaviour when overflow would occur, so that all you have to do is ensure that your re-arrangement doesn't cause overflow that wouldn't have happened otherwise. Optimizing the above expression to 'a' never does this. Of course, this might not be consistent with what a particular machine does with overflow, but I doubt that the standard requires consistent overflow behaviour. -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin