| dc.description.abstract | We have shown how GHC can have unpredictable results when it comes to its Core optimisation pipeline.
We motivated why existing techniques to analyze the output of the core2core pipeline are unsatisfactory.
We then proposed our custom tool hs-sleuth to aid in this discovery process. During the development
of hs-sleuth, we set out to answer a number of questions (Section 1.4) which have since been answered.
We answer them here explicitly for completeness’s sake.
Main Question How can GHC’s core2core passes be captured and presented in such a way that users
productively gain insight into how their code is transformed?
A snapshot of the current state of the program can be captured by embellishing the core2core pipeline with
snapshot passes via GHC’s plugin interface. The captured ASTs can be pretty printed in a web application
to provide interactive features such a hovering, clicking, dragging, and highlighting. By providing various
suppression options, the Core snapshots can be presented such that they nearly resemble canonical Haskell
source code. Finally, by allowing users to scroll through time, they can quickly observe if and when their
expectations are not met.
Sub-Question 1 How does one efficiently identify where small changes occur in two or more captures?
While a novel tree diff approach might prove more usefull, matching toplevel definitions by a hash of their
body is a productive approach to highlight deviations among captures.
Sub-Question 2 How to make viewing core more manageable using various display options?
Allowing programmers to hide as much irrelevant information as is sensible for the goal at hand is a
key part to ensure manageability. Moreover, making information such as variable names manually more
precise significantly reduces the mental strain of reading the Core.
Sub-Question 3 How could performance regressions that have occurred in the past in popular Haskell
projects, have been resolved faster?
As hs-sleuth lowers the bar to entry for analysing Core, we think that it will similarly become a more
approachable task for developers to confirm their optimisation approaches and subsequently guard against
regressions using non-functional tests. | |
