Re: "dataflow rewriting engine"
Manuel M T Chakravarty wrote:
> Deborah Goldsmith:
>> Has there been any thought about working with the LLVM project? I
>> didn't find anything on the wiki along those lines.
>
> I have only had a rather brief look at LLVM, but my understanding at the
> moment is that LLVM would not be able to support one of GHC's current
> code layout optimisations. More precisely, with LLVM, it would not be
> possible to enforce that the meta data for a closure is placed right
> before (in terms of layout in the address space) the code executing the
> "eval" method of that same closure. GHC uses that to have the closure
> code pointer point directly to the "eval" code (and hence also by an
> appropriate offset) to the various fields of the meta data. If that
> layout cannot be ensured, GHC needs to take one more indirection to
> execute "evals" (which is a very frequent operation) - this is what an
> unregistered build does btw.
>
> However, I am not convinced that this layout optimisation is really
> gaining that much extra performance these days. In particular, since
> dynamic pointer tagging, very short running "evals" (for which the extra
> indirection incurs the largest overhead) have become less frequent.
> Even if there is a slight performance regression, I think, it would be
> worthwhile to consider giving up on the described layout constraint. It
> is the Last Quirk that keeps GHC from using standard compiler back-ends
> (such as LLVM), and I suspect, it is not worth it anymore.
>
> When we discussed this last, Simon Marlow planned to run benchmarks to
> determine how much performance the layout optimisation gains us these
> days. Simon, did you ever get around to that?
(Continue reading)
RSS Feed