Path: utzoo!attcan!uunet!cs.utexas.edu!wuarchive!decwrl!ucbvax!bloom-beacon!mintaka!spdcc!esegue!compilers-sender From: spot@TR4.GP.CS.CMU.EDU (Scott Draves) Newsgroups: comp.compilers Subject: Re: Compilers taking advantage of architectural enhancements Keywords: design, optimize Message-ID: <1990Oct12.231155.1342@esegue.segue.boston.ma.us> Date: 12 Oct 90 04:22:51 GMT References: <1990Oct9> <3300194@m.cs.uiuc.edu> Sender: compilers-sender@esegue.segue.boston.ma.us Reply-To: spot@TR4.GP.CS.CMU.EDU (Scott Draves) Organization: Carnegie Mellon University Lines: 33 Approved: compilers@esegue.segue.boston.ma.us [Copied from comp.arch -John] |> >>Register file - large (around 128 registers, or more) |> >> Most compilers do not get enough benefit from these to justify |> >> the extra hardware, or the slowed down register access. |> > |> >In the proceedings of Sigplan 90, there's a paper about how to chew |> >lots of registers. |> > |> > Improving Register Allocation for Subscripted Variables |> > Callahan, Carr, Kennedy |> > |> >I suggested the subtitle "How to use of all those FP registers" |> >but nobody was impressed. Also, there's a limit to how many registers |> >you need, at least for scientific fortran. It depends on the speed |> >of memory and cache, speed of the FPU, and the actual applications. |> >The idea is that once the FPU is running at full speed, |> >more registers are wasted. |> shouldn't loop unrolling burn lots of registers also? when unrolling, which ceiling will you hit first, the number of registers, or the size of the I-cache? Scott Draves spot@cs.cmu.edu [A friend at Multiflow told me that the large register file was crucial to get serious unrolling speedups. There was some rather tricky work balancing unrolling vs. avoiding register saves by using otherwise unused registers in leaf routines. -John] -- Send compilers articles to compilers@esegue.segue.boston.ma.us {ima | spdcc | world}!esegue. Meta-mail to compilers-request@esegue.