tege@sics.se (Torbj|rn Granlund) (01/21/91)
--text follows this line-- I have been told that gcc generated code sometimes runs slower than cc generated code, in spite of its "better quality and smaller size". The problems seems to be that the tr registers are faster than other register categories on the MIServers, and that gcc uses these last, and cc uses them first. Fortunately, this is easy to fix. If anyone is interested, please contact me by email, and I'll send you the patch needed. -- Torbjorn Granlund (tege@sics.se, tege@ai.mit.edu)
hyerle@pyrthoth.pyramid.com (Robert H. Hyerle) (01/22/91)
In article <1991Jan20.180348.5004@sics.se> tege@sics.se (Torbj|rn Granlund) writes: >I have been told that gcc generated code sometimes runs slower than cc >generated code, in spite of its "better quality and smaller size". > >The problems seems to be that the tr registers are faster than other >register categories on the MIServers, and that gcc uses these last, >and cc uses them first. > Differing register speed is not the problem because all registers in the MIServer have identical, single cycle access times. I am not familiar with the gcc code but one possible answer is that the MIServer has various hardware artifacts (such as an execution pipeline) that complicate code generation with respect to performance. The Pyramid compiler group spent quite a bit of effort building an instruction scheduling component into "cc" and choosing appropriate instructions in an effort to improve performance. Without an understanding of the underlying hardware, generating quality code is not really possible. -- robert hyerle
rbj@uunet.UU.NET (Root Boy Jim) (01/24/91)
In article <141873@pyramid.pyramid.com> hyerle@pyrthoth.pyramid.com (Robert H. Hyerle) writes: >Without an understanding of the underlying hardware, >generating quality code is not really possible. And Pyramid doesn't tell anyone how their machine works. Or has that policy been changed? -- Root Boy Jim Cottrell <rbj@uunet.uu.net> Close the gap of the dark year in between