Pass Activity Log

AndrewMacLeod < >

The goal of the initial stages of this project is to provide some feedback on how useful passes are to the compilation process. We currently run 100's of passes all the time, and we don't really know how effective or necessary many of them are. We also don't know whether the cleanups they run are truly doing much. It would be nice to do some actual analysis and do something with the results.

nothing is committed yet, but the branch where the work will take place is in ' pass-activity-log '

For the moment, I'll just copy the text of my initial note here to provide the idea of what this is about. I'll rewrite chunks of this as I work out more details and define it better.

So I was thinking that maybe we could modify passes to report what they did. When CHECKING_ENABLED is on (or something like that), every pass reports what it did, possibly to the pass manager. Initially I was thinking it might have something like:

And then a report is issued for the compilation listing every pass that ran and a summary of this data for each occurrence. Each of the TODO cleanups run by each pass should also have its data listed.

Then we could run the compiler over a whack of testcases, accumulate all these reports, and generate some data on which passes and cleanups are not doing very much and are candidates for closer inspection.

One could then turn off one or more of these passes, run again, and see whether there appeared to be much impact on the other passes. A closer inspection may identify that perhaps the pass should be somewhere else in the pipeline, run only at -O3, completely eliminated, or modified in some way.

There are also categories of optimizations:

And these should probably be treated differently.

Enablers tend to work in concert with optimizations and sometime also cleanups. You need to look at the data for them together to see if useful work was done. If the cleanup is usually undoing everything the enabler did, then the enabler isn't really enabling, its just chewing cycles :-) (or there is a flaw in the optimization, in any case, it all deserves a closer look if the group isn't accomplishing much)

It also possible that a pass should only be run on a specific architecture or set of arches. I see no reason why we shouldn't allow the pass pipeline to be tuned for specific architectures. Not everything that is good for a 32 register machine is good for one with 8 registers and vice versa.

This could then be further extended into the RTL passes, and there are some other extensions that could be useful. It would be nice for instance if we could statically guess at whether the runtime was affected or not, and by how much.

Many modifications that optimizations make aren't really going to be measurable by simply testing execution speed.

And so on. Once properly set up, you could actually automate quite a bit of this and maybe get some very interesting data.

I think it would also be a good idea to set up a generic logging mechanism for this. There are other tasks within the compiler that a generic logging mechanism would be useful for. I've seen requests for optimizers to generate reports on what they did or didn't do and why, providing hints to the programmer about how to change their code to get better optimizations. I think we even had/have a branch for this sort of thing. It seems like a good opportunity to get something generic in place for future use.

None: Pass Activity Log (last edited 2008-02-21 23:29:18 by AndrewMacLeod)