LENS Logo

Overview

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.

News Feed for LENS News

February 10, 2006: The LENS project now has a website. Check back for information about the project, or subscribe to the feed Feed for LENS News for automatic updates.

Publications

Examples

The following are examples of the kind of information that map well to the LENS query scheme:

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.

Example Query in XML source: 
<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.
Example Tool Output: 
> 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 times
This is output from the loop-inspect tool, a simple tool written in Python that produces a custom report on loop metrics keyed by version.

People