Program Representation Size in an Intermediate Language with Intersection and Union Types

Dimock, Allyn; Westmacott, Ian; Muller, Robert; Turbak, Franklyn; Wells, J. B.; Considine, Jeffrey

doi:10.1007/3-540-45332-6_2

Cited by 5 publications

(9 citation statements)

References 29 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…3 We have experimented 2 Some defunctionalizing compilers avoid this run-time cost by using the appropriate code pointer as a "tag" in the generated object code and replacing the case dispatch by a jump, but their type systems do not support this as a well typed operation and hence this must be done in the code generator after types are erased. 3 We report on compile-time space costs of the CIL compiler in [16].…”

Section: Our Resultsmentioning

confidence: 99%

“…The CIL compiler uses flow types to manage the "plumbing" of the chosen representations, splitting sources and sinks as needed to ensure that all representations are used consistently relative to type and flow information. Despite complex types powerful enough to encode polyvariant flow analyses and term representations that duplicate the components of virtual records and the branches of virtual case expressions, the size of the intermediate representations of CIL programs is tractable in practice [16].…”

Section: Compiler Architecturementioning

confidence: 99%

“…In this paper, we report on the performance of the CIL 1 compiler for Standard ML [14,16]. The CIL compiler is a type-and flow-directed whole-program compiler which is designed to generate type-safe function representations that are customized for the contexts in which they are created and applied.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Functioning without closure

et al. 2001

Self Cite

View full text Add to dashboard Cite

The CIL compiler for core Standard ML compiles whole ML programs using a novel typed intermediate language that supports the generation of type-safe customized data representations. In this paper, we present empirical data comparing the relative efficacy of several different flow-based customization strategies for function representations. We develop a cost model to interpret dynamic counts of operations required for each strategy. In this cost model, customizing the representation of closed functions gives a 12-17% improvement on average over uniform closure representations, depending on the layout of the closure. We also present data on the relative effectiveness of various strategies for reducing representation pollution, i.e., situations where flow constraints require the representation of a value to be less efficient than it would be in ideal circumstances. For the benchmarks tested and the types of representation pollution detected by our compiler, the pollution removal strategies we consider often cost more in overhead than they gain via enabled customizations. Notable exceptions are selective defunctionalization, a function representation strategy that often achieves significant customization benefits via aggressive pollution removal, and a simple form of flow-directed inlining, in which pollution removal allows multiple functions to be inlined at the same call site.

show abstract

Section: Our Resultsmentioning

confidence: 99%

Section: Compiler Architecturementioning

confidence: 99%

See 1 more Smart Citation

Functioning without closure

et al. 2001

Self Cite

View full text Add to dashboard Cite

show abstract

“…The main benefit of λ B will be to make it easier to use technology (both theories and software) already developed for the λ-calculus on typed terms in a type system having the power and flexibility of intersection types. Due to the experimental performance measurements reported in [7], we do not expect a substantial size benefit in practice from λ B over λ CIL . In the area of logic, λ B terms may be useful as typed realizers of the so-called strong conjunction, but we are not currently planning on investigating this ourselves.…”

Section: Summary Of Contributions (Ie the Conclusion)mentioning

confidence: 99%

“…Using a TIL increases reliability of compilation and can support useful type-directed program transformations. We use intersection types because they support both more accurate analyses (as mentioned above) and interesting type/flow-directed transformations [5,19,7,6] that would be very difficult using ∀-quantified types. When using a TIL, it is important to regularly check that the intermediate program representation is in fact well typed.…”

Section: Background and Motivationmentioning

confidence: 99%

Branching Types

Wells¹,

Haack²

2002

Programming Languages and Systems

View full text Add to dashboard Cite

Abstract. Although systems with intersection types have many unique capabilities, there has never been a fully satisfactory explicitly typed system with intersection types. We introduce λ B with branching types and types which are quantified over type selectors to provide an explicitly typed system with the same expressiveness as a system with intersection types. Typing derivations in λ B effectively squash together what would be separate parallel derivations in earlier systems with intersection types.

show abstract