From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: Toon Moene Cc: egcs@cygnus.com Subject: Re: More than you ever wanted to know about Fortran array indexing ;-) Date: Mon, 13 Oct 1997 09:27:00 -0000 Message-id: <29618.876760173@hurl.cygnus.com> References: <9710091754.AA05699@moene.indiv.nluug.nl> X-SW-Source: 1997-10/msg00496.html In message < 9710091754.AA05699@moene.indiv.nluug.nl >you write: > Pah, it probably means the PA is broken as an architecture :-) - :-) :-) I've said this more than once myself. > I've tried it on machines as far apart as DEC Alpha and Motorola > m68k - all Fortran code I throw at it gets compiled to better code > *with* your `USE' patch; certainly all others (with possibly the x86 > as the sole exception) must fall between these extremes ... Hmmm. It's always possible I goof'd something during my benchmark runs. Basically what I saw was inner loops improving, but one level out there was _severe_ code explosion -- enough that improvements in the inner loops were completely negated. There's also the possibility the slowdown is PA specific due to quirks in the PA's addressing modes. > Oh, BTW, making combine_givs_p accept all possible candidate givs > for combining does not result in much improvement, because the > return value of this function is but one of the (half a dozen) > conditions that have to be fulfilled before giv G2 can be combined > with giv G1 (see the routine combine_givs, i.e. without `_p'). Yup. Found that out myself when I briefly looked at the PA slowdowns. > Obviously, this could work correctly if every giv could have a > _list_ of other givs that could be combined with it, and > combine_givs computed the transitive closure of the > G2-combines-with-G1 relation (checking, in the mean time, that the > computational relationship remained a valid addressing mode). > > But that requires `some' more work ;-) A "simple" matter of hacking :-) :-) jeff