[LLVMdev] RFC - Adding an optimization report facility? (original) (raw)

Diego Novillo dnovillo at google.com
Wed Mar 12 06:59:07 PDT 2014

On Tue, Mar 11, 2014 at 10:42 PM, Gerolf Hoflehner <ghoflehner at apple.com> wrote:

This feature will be very useful and I suggest taking a bigger perspective.

Not only the major decisions but also simple optimizations metrics like #, #spills etc can be useful for performance analysis, comparison and tracking. In addition to metrics locality is helpful, specifically a report at a function level. A good place to start and test the design could be to issue current --stats per function. In practice the users of these reports know the hot functions and like to drill down.

Right. Once the base reporting harness is in place, adding calls from the optimizers can be done incrementally. Initially, the major passes (inliner, vectorizer, scalar loop optimizers, etc). Mapping stats info into this report may be doable, but it needs to be something actionable and understandable by end-users. A stats report that refers to something obscure like 'eliminated N% of phi nodes' does not seem to be something useful. Stats also tend to be harder to place at a src loc.

The reports themselves could offer various levels of verbosity for the user to pick (and the implementer to decide which information to report at which level).

That's reflected in the document, yes. Adding levels of verbosity could be doable.

For performance tuning a compiler that also reports why it didn't apply an optimization can be very useful (like in "I didn't vectorize because of this dependency." etc.).

Yes. Also reflected in the document.

Diego.

More information about the llvm-dev mailing list