Re: Looking for backend timing info (Preston Briggs)
Fri, 4 Jun 1993 14:25:12 GMT

          From comp.compilers

Related articles
Looking for backend timing info (1993-06-04)
Re: Looking for backend timing info (1993-06-04)
Re: Looking for backend timing info chased@rbbb.Eng.Sun.COM (1993-06-04)
Re: Looking for backend timing info (1993-06-06)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Preston Briggs)
Keywords: performance
Organization: Rice University, Houston
References: 93-06-010
Date: Fri, 4 Jun 1993 14:25:12 GMT (Mark Nelson) writes:
>I'm looking for hard data on the time costs of analysis and optimization
>in compiler back-ends. Has anyone instrumented a compiler back-end to
>extract this sort of information? I'm especially interested in data
>for compilers for massively parallel machines, but anything along these
>lines would be a help.

Interestingly, you say "back-ends" and "massively parallel machines". I
usually think of most of the parallelism-related effort as occuring
relatively early, with the back end being devoted to traditional scalar
optimizations for the particular processor node.

At any rate, most industrial compilers have flags that'll force them to
tell you where they spend their time. For example, on IBM's xlf and xlc
compilers for the RS/6000,

xlf -c -O -qphsinfo zap.f

will show the time spent in each of 4 phases (ftphas1, optimize, regalloc,
and assembly).

On some versions of the MIPS compilers, you could use

f77 -c -O -Wo,-l,logfile zap.f

to force somewhat more detailed timing out to the file "logfile".

I don't know about compilers for the CM5 or Maspar; perhaps prowling the
man pages will yield the flags you're looking for. Or perhaps they are
undocumented and you'll have to ask the vendor, nicely. Compiler people
within the companies are often willing to give out this info, though the
flags won't always be officially supported.

Preston Briggs

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.