The LENS project is intended to improve the task of measuring programs and investigating their behavior.
LENS defines an external representation of a program in XML to store useful information that is accessible based on program structure, including loop info.
LENS defines a flexible naming scheme for program components based on XPath and the LENS XML document structure. This allows users and tools to selectively query program behavior from a uniform interface, allowing users or tools to ask a variety of questions about program components, which can be answered by any tool that understands the query. This selectivity is important to avoid information overload.
Queries, metrics and program structure are all stored in the LENS file, and are annotated with version names that support historical comparison and scientific record-keeping.
Compiler writers can use LENS to expose results of transformations and analyses for a program easily, without worrying about display or handling information overload. This functionality has been demonstrated using the LLVM Compiler Framework.
Please direct any inquiries about the project to Michael O. McCracken.
- McCracken, Michael O. The Design and Implementation of The LENS Program Information Framework, Tech. Rep. UCSD CSE, Feb. 2006 (download PDF)
- Was a particular optimization performed on the loop at a given location in source?
- What optimizations were attempted but failed on a given procedure?
- For any block in a particular loop, what is the cache miss rate? (or any other hardware counter metric)
- Were any loops in the program not unrolled, and if not, why?
- How many times was
malloc()called from within a given procedure during execution?
Many other kinds of information fit well in LENS, including code coverage, bug statistics, and test results. Using LENS gives a single interface for tools to access all that information and adds the ability to perform historical comparison with versions.
Some kinds of information are not naturally stored as metrics attached to program code structure. Communication event trace data is an important example. There are many useful tools for viewing and analyzing trace data, and LENS does not directly address that task. However, often the reason for gathering event traces is to answer a question which could be formed as a LENS-style query.
<query requestingToolName="lensh" label="loopUnrollQuery" date="2004-05-01-19:31gmt-4" versionLabel="version1" xpath="/pmf/module/procedure/loop" metricName="/llvm/optimizations/loopunroll/reasons/"/>This query is asking for reasons the loop unroll optimization was not performed on any loop in the program. It corresponds to the last question in the list above.
> loop-inspect info simpleUnroll.pmf --versions=ppc,x86 Showing metrics from these versions: ppc of Wed Nov 9 12:34:44 2005 PST configuration-3 ['darwin'] x86 of Wed Nov 9 12:38:12 2005 PST configuration-4 ['darwin'] simpleUnroll.bc compiled from ./simpleUnroll.c - main no_exit.0 (59, 191) ppc: Visited, too large to unroll no_exit.1 (64, 69) ppc: Visited, too large to unroll no_exit.2 (66, 67) ppc: Visited, Unrolled 4 times x86: 4 spills no_exit.0.i (185, 263) ppc: Visited, too large to unroll no_exit.1.i (188, 263) ppc: Visited, Unrolled 4 times x86: 4 spills no_exit.3 (76, 77) ppc: Visited, Unrolled 4 times no_exit.4 (86, 175) ppc: Visited, too large to unroll no_exit.7 (107, 114) ppc: Visited, too large to unroll no_exit.8 (110, 112) ppc: Visited, non-constant trip count no_exit.9 (122, 123) ppc: Visited, Unrolled 4 times no_exit.10 (134, 175) ppc: Visited, too large to unroll no_exit.11 (140, 155) ppc: Visited, too large to unroll no_exit.12 (142, 143) ppc: Visited, non-constant trip count no_exit.13 (145, 153) ppc: Visited, non-constant trip count no_exit.14 (163, 164) ppc: Visited, Unrolled 4 timesThis is output from the loop-inspect tool, a simple tool written in Python that produces a custom report on loop metrics keyed by version.