🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #2182

Re: Dyn Byrnstyn is a RADIKUL DOOD

#2182
From: Dan Bernstein
Date: Mon, 19 Nov 1990 20:40
50 lines
2903 bytes
In article <1990Nov18.033622.1517@murdoch.acc.Virginia.EDU> gl8f@astsun9.astro.virginia.edu (Greg Lindahl) writes:
> In article <14780:Nov1605:10:4490@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> [ after insulting gcc, claiming it can't get strength reduction
> correctly ]

As a matter of fact, my ``insults'' were correct. Michael Meissner
posted an article pointing out that gcc converts multiplication into a
subroutine call on the Sparc, then fails to recognize the call during
optimization. Greg, f*ck off. (Pardon my French, but the level of Greg's
rhetoric is getting rather sickening.)

> >All you wanted was real examples for real optimizers. I had thought that
> >you were listening when other people posted real examples. Apparently
> >not. Now I've posted the examples for you.
> And your examples are wrong. Please, before you post any more
> examples, check them for careless errors.

My examples are right, and I most certainly did check for mistakes.

> Stop misrepresenting mine. No existing compiler does the necessary
> analysis. No compiler can do an anlysis as strict as the FORTRAN
> anti-aliasing requirement. See my previous postings for the example
> that breaks your technique. You never replied to my example.

I haven't seen any such example. What was the message-id?

> I guess you
> find non-local analysis easier than analysis that doesn't have to go
> outside of the basic block.

No, I don't. If you understood the aliasing detection mechanism I've
been talking about, you'd know that it does not require non-local or
interprocedural analysis. (I think Jim finally accepts this fact.)

If you're willing to do some non-local analysis, you can decide
partitions on the basis of global use of variables. But the basic method
doesn't depend on that.

> And, finally, I guess you don't remember that I suggested that
> comparing the starting addresses of arrays could lead to significant
> optimizations quite a while ago

Lots of people have suggested this, so you're right: I don't remember
you in particular saying it. (The sorting thread started because I had
pointed out the same run-time solution to Jim, and he didn't think
comparing the addresses of n arrays could be done in linear time.)
Anyway, a compile-time solution is always better than a run-time
solution.

---Dan
Technical Details
Message-ID: <28149:Nov1920:40:3590@kramden.acf.nyu.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!adm!cmcl2!kramden.acf.nyu.edu!brnstnd
References: <6096@lanl.gov> <14780:Nov1605:10:4490@kramden.acf.nyu.edu> <1990Nov18.033622.1517@murdoch.acc.Virginia.EDU>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!adm!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.misc
Subject: Re: Dyn Byrnstyn is a RADIKUL DOOD
Message-ID: <28149:Nov1920:40:3590@kramden.acf.nyu.edu>
Date: 19 Nov 90 20:40:35 GMT
References: <6096@lanl.gov> <14780:Nov1605:10:4490@kramden.acf.nyu.edu> <1990Nov18.033622.1517@murdoch.acc.Virginia.EDU>
Organization: IR
Lines: 50