Hostname: page-component-78c5997874-fbnjt Total loading time: 0 Render date: 2024-11-04T21:29:20.556Z Has data issue: false hasContentIssue false

Constructed product result analysis for Haskell

Published online by Cambridge University Press:  22 January 2004

CLEM BAKER-FINCH
Affiliation:
Department of Computer Science, The Australian National University, Canberra ACT 0200, Australia (e-mail: [email protected])
KEVIN GLYNN
Affiliation:
Department of Computer Science, The University of Melbourne, Melbourne, Australia (e-mail: [email protected])
SIMON PEYTON JONES
Affiliation:
Microsoft Research, Cambridge, UK (e-mail: [email protected])
Rights & Permissions [Opens in a new window]

Abstract

Core share and HTML view are not available for this content. However, as you have access to this content, a full PDF is available via the ‘Save PDF’ action button.

Compilers for ML and Haskell typically go to a good deal of trouble to arrange that multiple arguments can be passed efficiently to a procedure. For some reason, less effort seems to be invested in ensuring that multiple results can also be returned efficiently. In the context of the lazy functional language Haskell, we describe an analysis, Constructed Product Result (CPR) analysis, that determines when a function can profitably return multiple results in registers. The analysis is based only on a function's definition, and not on its uses (so separate compilation is easily supported) and the results of the analysis can be expressed by a transformation of the function definition alone. We discuss a variety of design issues that were addressed in our implementation, and give measurements of the effectiveness of our approach across a substantial benchmark set. Overall, the price/performance ratio is good: the benefits are modest in general (though occasionally dramatic), but the costs in both complexity and compile time, are low.

Type
Article
Copyright
© 2004 Cambridge University Press
Submit a response

Discussions

No Discussions have been published for this article.