GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&type=task&order=owner
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&type=task&order=owner
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/8226
http://ghc.haskell.org/trac/ghc/ticket/8226#8226: Remove the old style -- # Haddock comments.Thu, 05 Sep 2013 01:15:45 GMTFuuzetsu<p>
Haddock 0.x supported -- # style comments for Haddock pragma and while this seems to have been long forgotten and not documented, it's still kicking in the lexer. I think this is a good time to get rid of these all together.
</p>
<p>
Relevant Haddock ticket <a class="ext-link" href="http://trac.haskell.org/haddock/ticket/171"><span class="icon"></span>http://trac.haskell.org/haddock/ticket/171</a>
</p>
<p>
I'll hopefully send in patches removing these from the lexer/parser tomorrow, if all goes well (unless anyone feels eager to do it, then please, you're most welcome to do so!).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8226#changelog
http://ghc.haskell.org/trac/ghc/ticket/10061
http://ghc.haskell.org/trac/ghc/ticket/10061#10061: Remove fun_infix from Funbind, as it is now in MatchMon, 02 Feb 2015 22:01:26 GMTalanz<p>
One of the changes <a class="ext-link" href="https://phabricator.haskell.org/D538" title="D538 in Phab"><span class="icon"></span>Phab:D538</a> introduced is to add m_fun_id_infix to Match
</p>
<div class="code"><pre><span class="kr">data</span> <span class="kt">Match</span> id body
<span class="ow">=</span> <span class="kt">Match</span> <span class="p">{</span>
m_fun_id_infix <span class="ow">::</span> <span class="p">(</span><span class="kt">Maybe</span> <span class="p">(</span><span class="kt">Located</span> id<span class="p">,</span><span class="kt">Bool</span><span class="p">)),</span>
<span class="c1">-- fun_id and fun_infix for functions with multiple equations</span>
<span class="c1">-- only present for a RdrName. See note [fun_id in Match]</span>
m_pats <span class="ow">::</span> <span class="p">[</span><span class="kt">LPat</span> id<span class="p">],</span> <span class="c1">-- The patterns</span>
m_type <span class="ow">::</span> <span class="p">(</span><span class="kt">Maybe</span> <span class="p">(</span><span class="kt">LHsType</span> id<span class="p">)),</span>
<span class="c1">-- A type signature for the result of the match</span>
<span class="c1">-- Nothing after typechecking</span>
m_grhss <span class="ow">::</span> <span class="p">(</span><span class="kt">GRHSs</span> id body<span class="p">)</span>
<span class="p">}</span> <span class="kr">deriving</span> <span class="p">(</span><span class="kt">Typeable</span><span class="p">)</span>
</pre></div><p>
This was done to track the individual locations and fixity of the fun_id for each of the defining equations for a function when there are more than one.
</p>
<p>
For example, the function (&&&) is defined with some prefix and some infix equations below.
</p>
<div class="code"><pre>
<span class="p">(</span><span class="o">&&&</span> <span class="p">)</span> <span class="kt">[]</span> <span class="kt">[]</span> <span class="ow">=</span> <span class="kt">[]</span>
<span class="nf">xs</span> <span class="o">&&&</span> <span class="kt">[]</span> <span class="ow">=</span> xs
<span class="p">(</span> <span class="o">&&&</span> <span class="p">)</span> <span class="kt">[]</span> ys <span class="ow">=</span> ys
</pre></div><p>
This means that the fun_infix is now superfluous in the FunBind. This has not been removed as a potentially risky change just before 7.10 RC2, and so must be done after.
</p>
<p>
This ticket captures that task, which includes processing these fields through the renamer and beyond.
</p>
<p>
Ticket <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/9988" title="task: Remove fun_id, is_infix from FunBind, as they are now in Match (closed: fixed)">#9988</a> introduced these fields into Match through renaming, this ticket it to continue through type checking and then remove it from FunBind completely.
</p>
<p>
The split happened so that <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/9988" title="task: Remove fun_id, is_infix from FunBind, as they are now in Match (closed: fixed)">#9988</a> could land in 7.10
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/10061#changelog
http://ghc.haskell.org/trac/ghc/ticket/4438
http://ghc.haskell.org/trac/ghc/ticket/4438#4438: Rename and register the "PArr" language extension when it is judged to be readyMon, 25 Oct 2010 18:47:06 GMTduncan<p>
Language extensions used in distributed packages need to be registered in <tt>Language.Haskell.Extension</tt> (which currently lives in the Cabal lib).
</p>
<p>
When the DPH hackers think that the <tt>PArr</tt> extension is ready for public consumption then they should register it. It will need to be renamed to something more descriptive, see the <tt>Language.Haskell.Extension</tt> module for examples. The style is to use full words. Perhaps <tt>ParallelArrays</tt> would be an appropriate choice.
</p>
<p>
Currently the <tt>PArr</tt> extension is the only GHC extension that is deliberately not registered (there are others that are accidentally not registered). It is listed as an exception in the testsuite test that checks for GHC extensions that are accidentally not registered. See ticket <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4437" title="bug: unregistered language extensions (closed: fixed)">#4437</a>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4438#changelog
http://ghc.haskell.org/trac/ghc/ticket/7883
http://ghc.haskell.org/trac/ghc/ticket/7883#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?Thu, 02 May 2013 20:38:14 GMTcarter<p>
LLVM provides a number of atomicity / memory ordering primitives.
</p>
<p>
currently the CAS primops exposed at the CMM level are ffi'd inline assembly fun calls. this means that for certain concurrency primops, we've got fun calls within funcalls that could be easily inlined if we did it in a more llvm direct way. A notable example of this is the implementation of <tt> stg_atomicModifyMutVarzh </tt>
</p>
<p>
relevant basic llmv docs are the following
<a class="ext-link" href="http://llvm.org/docs/LangRef.html#cmpxchg-instruction"><span class="icon"></span>Atomic llvm ops</a>
</p>
<p>
<a class="ext-link" href="http://llvm.org/docs/Atomics.html"><span class="icon"></span>semantics of the various ordering levels</a>
</p>
<p>
relevant locations in the ghc source
<a class="ext-link" href="https://github.com/ghc/ghc/blob/master/includes/stg/SMP.h#L170"><span class="icon"></span>CAS inline assembly</a>
</p>
<p>
<a class="ext-link" href="https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm#L282"><span class="icon"></span>defn of atomicModifyMutVar cmm code</a>
</p>
<p>
Based upon my reading of the relevant GHC cmm code, and reading the semantics of the LLVM operations, the right level of atomic ordering in the generated bit code would be "SequentiallyConsistent".
</p>
<p>
a first step would be to modify the CMM -> LLVM pass to substitute the cas funcall with the right llvm operation. This <strong> SEEMS </strong> like it'd be very very easy to do and low hanging fruit.
</p>
<p>
Theres a few upsides that <strong> might </strong> come out of this.
</p>
<ol><li> would be easy to augment to also provide a doubleCAS primitive, which would be useful in writing various lock free data structures.
</li><li> would increase the portability / ease of retargeting new platforms / hardware via LLVM. (not needing to worry about the target's memory consistency model / write new cases of inline assembly)
</li><li> (this would need benchmarks) could potentially improve the performance of certain heavy concurrency operations by eliminating a funcall in an otherwise tight loop.
</li><li>Theres probably other interesting possible upside, such as perhaps having more of the rts be nicely writeable in CMM? (esp since theres now native funcall support)
</li><li>Also would make the CMM memory model a bit more explicit perhaps?
</li></ol><p>
</p>
<p>
This seems like a *relatively* managable patch to write. I'm up for spending time on this if, should it work, it'd be likely to be merged in.
</p>
<p>
it'd also be a good warm up for a number of other things I want to do, including <a class="ext-link" href="http://hackage.haskell.org/trac/ghc/ticket/5567#comment:10"><span class="icon"></span>http://hackage.haskell.org/trac/ghc/ticket/5567#comment:10</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7883#changelog
http://ghc.haskell.org/trac/ghc/ticket/8272
http://ghc.haskell.org/trac/ghc/ticket/8272#8272: testing if SpLim=$rbp and Sp=$rsp changed performance at allThu, 12 Sep 2013 05:45:51 GMTcarter<p>
testing if SpLim=$rbp and Sp=$rsp changed performance at all
</p>
<blockquote>
<p>
would need a stack check but then push could be used to spill to the stack
</p>
</blockquote>
<p>
Idea via Nathan Howell.
</p>
<p>
At the very least, the x86 PUSH instruction has a more succinct encoding than MOV.
</p>
<p>
worth hacking out to see if this can measurable shift ghc perf on nofib or not.
</p>
<p>
this would be part of a larger effort to explore ways to improve GHC's calling convention for modern hardware
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8272#changelog
http://ghc.haskell.org/trac/ghc/ticket/9276
http://ghc.haskell.org/trac/ghc/ticket/9276#9276: audit ghc floating point support for IEEE (non)complianceSun, 06 Jul 2014 19:45:08 GMTcarter<p>
As best I can determine, ghc has never been closely audited for conformance to IEEE-754 (floating point) standard and currently is a bit far from providing a compliant implementation.
</p>
<p>
This impacts both a number of other tasks i wish to do for ghc <strong>and</strong> much of my own use of haskell is in a floating point heavy workloads, I will do a bit of leg work to:
</p>
<blockquote>
<p>
a) improve test suite support for checking for compliance
b) write some patches to provide portable compliant primops for the operations which need compiler support
c) try to determine how to allow ghc optimizer to be a bit more aggressive in a sound way in the presence of floating point.
</p>
</blockquote>
<p>
(this may grow into a few subtickets, we'll see)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9276#changelog
http://ghc.haskell.org/trac/ghc/ticket/9496
http://ghc.haskell.org/trac/ghc/ticket/9496#9496: Simplify primitives for short cut fusionThu, 21 Aug 2014 20:55:02 GMTdfeuer<p>
Currently, there appear to be two production primitives, <tt>build</tt> and <tt>augment</tt> (although I may have missed some). There are multiple consumption primitives (at least: <tt>foldr</tt>, <tt>head</tt>, <tt>and</tt>, <tt>or</tt>, <tt>any</tt>, and <tt>all</tt>). The rule sets for some producers seem to forget to handle <tt>augment</tt>, and the <tt>augment/augment</tt> rule is omitted as "true, but not, I think, useful".
</p>
<p>
A number of other functions are instead rewritten into <tt>foldr</tt> forms, and then written back if they don't fuse.
</p>
<h2 id="Whattodo:">What to do:</h2>
<p>
Personally, I'd be very tempted to start by saying <tt>build g = augment g []</tt> (or <em>possibly</em> even <tt>build g = extend [] g []</tt> if I can ever get that idea to work) and cut the problem in half. The main problem I see with this is if other people are importing <tt>GHC.Exts</tt> or <tt>GHC.Base</tt>, writing things with <tt>build</tt>, and expecting them to fuse. One way to deal with this, perhaps, is to hack a special rule into the RULES compiler to recognize <tt>GHC.Base.build</tt> on the LHS of RULES and replace it with the appropriate <tt>augment</tt> form, emitting a warning.
</p>
<p>
Where to go after that: the question remains whether it's best in general to rewrite a form to <tt>foldr</tt> to make it fuse, or to fuse directly with <tt>augment</tt>. The answer presumably depends, at least in part, on whether there are additional <tt>foldr</tt>-based rules we may want to add that would take advantage of the effort put into the translation back from the <tt>foldr</tt> form. I would conjecture that most such rules we could want would go beyond what the RULES system actually can do. That said, if we can find a way to use <tt>foldr</tt> forms without the horrible pain of translating back from them, that would be a very good thing.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9496#changelog
http://ghc.haskell.org/trac/ghc/ticket/9797
http://ghc.haskell.org/trac/ghc/ticket/9797#9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate typesWed, 12 Nov 2014 17:24:23 GMTdfeuer<p>
When we see <tt>m >>= (\_ -> n)</tt> with a type that admits an optimized <tt>>></tt> or <tt><$</tt>, we should try to take advantage of that. I don't currently know if this applies to any types under "GHC HQ" control.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9797#changelog
http://ghc.haskell.org/trac/ghc/ticket/4211
http://ghc.haskell.org/trac/ghc/ticket/4211#4211: LLVM: Stack alignment on OSXFri, 23 Jul 2010 13:08:51 GMTdterei<p>
On OSX the ABI requires that the stack is 16 byte aligned when making function calls. (Although this only really needs to be obeyed when making calls that will go through the dynamic linker, so FFI calls). Since the stack is 16 byte aligned at the site of the call, on entry to a function most compilers (both llvm and gcc) expect the stack to now be aligned to 16n - 4, since 4 bytes should have been pushed for the return address as part of the call instruction. GHC though since it uses jumps everywhere keeps that stack at 16 byte aligned on function entrance. This means that LLVM generates incorrect stack alignment code, always off by 4.
</p>
<p>
For the moment I have handled this by using the LLvm Mangler (which is only needed on OS X already for TNTC) to simply correctly fix up the stack alignment code.
</p>
<p>
E.g Asm generated by LLVM:
</p>
<pre class="wiki">_func:
subl $12, %esp
...
call _sin
...
addl $12, %esp
</pre><p>
The mangler will change this to:
</p>
<pre class="wiki">_func:
subl $16, %esp
...
call _sin
...
addl $16, %esp
</pre><p>
The better solution would be to change GHC to keep the stack at 16n - 4 alignment on function. This will require changing the RTS (StgCRun.hs) to set the stack properly before calling into Stg land and also fixing up the NCG to align code properly. There may also be a problem with the C backend as currently all function prolouge and epilouge code is stripped out, which means all the stack manipulation code generated by GCC is removed. This works fine now since the stack is already 16 byte aligned on entry, but if it is now 16n - 4 byte aligned then some stack manipulation will be required.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4211#changelog
http://ghc.haskell.org/trac/ghc/ticket/5567
http://ghc.haskell.org/trac/ghc/ticket/5567#5567: LLVM: Improve alias analysis / performanceTue, 18 Oct 2011 18:21:24 GMTdterei<ul><li>LLVM doesn't generate as good as code as we feel it should in many situations
</li><li>Why?
<ul><li>We've often felt its a alias anlysis issue.
</li><li>I'm a little more doubtful of that than others (I feel its part of the bigger problem, not the whole thing).
</li><li>I think there may be some register allocation / instruction selection / live range splitting issue going on.
</li></ul></li><li>We could also do with looking at what optimisation passes we should run and in what order...
</li></ul><p>
Here is some work Max did on the alias issue, his results for nofib weren't good:
</p>
<p>
<a class="ext-link" href="http://blog.omega-prime.co.uk/?p=135"><span class="icon"></span>http://blog.omega-prime.co.uk/?p=135</a>
</p>
<p>
So this ticket is just a high level ticket about figuring out and improving the performance of LLVM backend.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5567#changelog
http://ghc.haskell.org/trac/ghc/ticket/5793
http://ghc.haskell.org/trac/ghc/ticket/5793#5793: make nofib awesomeWed, 18 Jan 2012 02:03:19 GMTdterei<p>
Nofib is the standard tool GHC developers use to benchmark changes to the compiler. Its overall design is OK but it's had no love and care for many years and has bittrotted such that it isn't useful in a lot of situations.
</p>
<p>
This task is about making nofib useful again.
</p>
<p>
The breakdown for this is something like:
</p>
<ol><li>Think and maybe fix nofib framework design. It has 'ways' which I think correspond to compilation method but more in the sense of 'dynamic' vs 'static', seems it may not suite being able to use ways for 'fasm' vs 'fllvm'. There is also the concept of 'modes' which corresponds to different benchmark input. So 'normal' and 'slow' for getting different run-times. At moment no easy way to select which benchmark groups to run, so may want to change that. I guess we should just decide, what knobs do we want to be able to easily tweak, and see how well the current design allows that.
</li></ol><p>
<strong>Note</strong> there is a shake build system attached that does a lot of this (done by Neil Mitchell!). An explanation of it can be found here: <a class="ext-link" href="http://neilmitchell.blogspot.com/2013/02/a-nofib-build-system-using-shake.html"><span class="icon"></span>http://neilmitchell.blogspot.com/2013/02/a-nofib-build-system-using-shake.html</a>
</p>
<p>
The design discussion of it is mostly lost as it was done on private email sorry.
</p>
<ol start="2"><li>Fixup the runtimes for benchmarks to be significant. This might be best done by changing the way we run benchmarks and collect results to make sure they are meaningful.
</li></ol><p>
E.g., Lots of great discussion and links to papers on this thread
</p>
<p>
<a class="ext-link" href="http://www.haskell.org/pipermail/ghc-devs/2013-February/000307.html"><span class="icon"></span>http://www.haskell.org/pipermail/ghc-devs/2013-February/000307.html</a>
</p>
<ol start="3"><li>Above task is to fix normal but we may want to fixup slow as well and perhaps add a 'fast' mode where benchmarks run in around 1 second.
</li></ol><ol start="4"><li>Maybe add more benchmarks to the suite (text, bytestring, performance regressions from ghc testsuite, vector....)
</li></ol>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5793#changelog
http://ghc.haskell.org/trac/ghc/ticket/8767
http://ghc.haskell.org/trac/ghc/ticket/8767#8767: Add rules involving `coerce` to the librariesTue, 11 Feb 2014 15:44:41 GMTnomeata<p>
With <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/2110" title="feature request: Rules to eliminate casted id's (closed: fixed)">#2110</a> fixed, we can now add rules like
</p>
<pre class="wiki">{-# RULES "map/coerce" [0] map coerce = coerce #-}
</pre><p>
to the standard libraries. But probably this should happen together or after <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/8718" title="task: Add role annotations to base (closed: fixed)">#8718</a>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8767#changelog
http://ghc.haskell.org/trac/ghc/ticket/9505
http://ghc.haskell.org/trac/ghc/ticket/9505#9505: Bounded instance for Word (and possibly others) uses explicitly unboxed literalsSat, 23 Aug 2014 00:07:11 GMTschyler<p>
There's a comment above saying GHC won't optimise. I think since 7.8 they are unboxed by default, so that comment and the explicit constructors can be removed.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9505#changelog
http://ghc.haskell.org/trac/ghc/ticket/9542
http://ghc.haskell.org/trac/ghc/ticket/9542#9542: GHC-IO-Handle-Text.hPutStr' and writeBlocks look like they need refactoringTue, 02 Sep 2014 14:47:53 GMTdfeuer<p>
The boundary between <tt>writeBlocks</tt> and <tt>hPutStr'</tt> looks badly drawn, with pieces of buffering type on either side. I would also speculate that one or more CRLF-related helper functions may be in order.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9542#changelog
http://ghc.haskell.org/trac/ghc/ticket/9674
http://ghc.haskell.org/trac/ghc/ticket/9674#9674: Foldable doesn't have any lawsFri, 10 Oct 2014 17:24:45 GMTdfeuer<p>
The documentation for <tt>Foldable</tt> doesn't list any laws. I don't know exactly what its laws may be, but there are, at least, several implicit in the default method definitions.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9674#changelog
http://ghc.haskell.org/trac/ghc/ticket/9682
http://ghc.haskell.org/trac/ghc/ticket/9682#9682: Implement "Add bifunctor related classes to base"-ProposalSun, 12 Oct 2014 14:46:32 GMThvr<p>
See <a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2014-April/022844.html"><span class="icon"></span>original libraries@ proposal</a> for more details
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9682#changelog
http://ghc.haskell.org/trac/ghc/ticket/9707
http://ghc.haskell.org/trac/ghc/ticket/9707#9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable`Mon, 20 Oct 2014 17:10:59 GMThvr<p>
<a class="closed" href="http://ghc.haskell.org/trac/ghc/ticket/9111#comment:16" title="Comment 16 for Ticket #9111">comment:ticket:9111:16</a> explains that import-cycles containing <tt>Data.Typeable.Internal</tt> (which provides the <tt>Typeable</tt> class <tt>AutoDeriveTypeable</tt> needs to be loaded for being able to operate) inside <tt>base</tt> make it difficult to use <tt>AutoDeriveTypeable</tt>, as well as making it more difficult to de-cycle the <tt>base</tt> import-dependency graph (see also <a class="attachment" href="http://ghc.haskell.org/trac/ghc/attachment/ticket/9707/typeable_deps.png" title="Attachment 'typeable_deps.png' in Ticket #9707">attachment:typeable_deps.png</a><a class="trac-rawlink" href="http://ghc.haskell.org/trac/ghc/raw-attachment/ticket/9707/typeable_deps.png" title="Download"></a>)
</p>
<p>
This ticket is about trying to find a way to restructure <tt>base</tt> in order to allow to define the <tt>Typeable</tt> instances directly at the type's definition site (and thus allow the use of <tt>AutoDeriveTypeable</tt>)
</p>
<p>
Removing cycles in <tt>base</tt> is possibly required to make <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/SplitBase">SplitBase</a> easier
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9707#changelog
http://ghc.haskell.org/trac/ghc/ticket/9716
http://ghc.haskell.org/trac/ghc/ticket/9716#9716: The list modules need a bit of post-BBP shakingThu, 23 Oct 2014 15:12:08 GMTdfeuer<p>
We currently have an unfortunately named <tt>Data.List.OldList</tt>, and no terribly clear story to explain it. One concept, due in part to me and in part to Carter:
</p>
<ol><li>Move all the basics needed to implement <tt>instance Foldable []</tt> from <tt>Data.OldList</tt> to <tt>Data.List.Base</tt> (or some similar name).
</li></ol><ol start="2"><li>Move all the "extras" like <tt>inits</tt>, <tt>tails</tt>, and <tt>sort</tt> from <tt>Data.OldList</tt> into <tt>Data.List</tt>.
</li></ol><ol start="3"><li>Delete <tt>Data.OldList</tt>.
</li></ol>Resultshttp://ghc.haskell.org/trac/ghc/ticket/9716#changelog
http://ghc.haskell.org/trac/ghc/ticket/5140
http://ghc.haskell.org/trac/ghc/ticket/5140#5140: Fix LLVM backend for PowerPCTue, 19 Apr 2011 22:15:32 GMTerikd<p>
LLVM backend does not work for PowerPC.
</p>
<p>
From bug <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/5131" title="bug: linux-powerpc : panic in stage1 compiler (closed: fixed)">#5131</a> davidt says the order of business is:
</p>
<pre class="wiki"> a) Get unregistered working.
b) Get registered without TABLES_NEXT_TO_CODE.
c) Get TABLES_NEXT_TO_CODE working.
d) Ask David where to go from there.
</pre><p>
Actually there is now a guide of sorts <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/GHC_LLVMPorting">here</a>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5140#changelog
http://ghc.haskell.org/trac/ghc/ticket/8489
http://ghc.haskell.org/trac/ghc/ticket/8489#8489: clean up dependency and usages handling in interface filesWed, 30 Oct 2013 11:13:24 GMTerrge<p>
While reviewing <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1480" title="feature request: Template Haskell should allow reification of modules (closed: fixed)">#1480</a>, it was found that there are corner cases that are not easy to handle.
</p>
<p>
This task is about fixing TH module reification to reify direct import list, not usages. For this we may need to extend the current <tt>ModIface</tt>.
</p>
<p>
This task also includes cleaning up the comments and code in related areas, to quote simonpj: "we need more precise commentary on the fields of <tt>HscTypes.Dependencies</tt>, <tt>TcRnTypes.ImportAvails</tt>, and <tt>mi_usages</tt> of <tt>ModIface</tt>. For example, I wonder whether the <tt>mi_usages</tt> field could be part of the <tt>Dependencies</tt>".
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8489#changelog
http://ghc.haskell.org/trac/ghc/ticket/1631
http://ghc.haskell.org/trac/ghc/ticket/1631#1631: Make the External Package Table contain ModDetails not ModIfaceThu, 23 Aug 2007 10:24:55 GMTsimonpj<p>
Currently the <tt>External Package Table</tt> contains <tt>ModIfaces</tt>. But that makes it hard to answer the question "which instances were introduced by module Foo" in the GHC API. See Kenny Lu's problem <a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-users/2007-August/013027.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-users/2007-August/013027.html</a>
</p>
<p>
Furthermore the <tt>ModIfaces</tt> in the EPS are cut-down ones, with decls etc trimmed off becuase they are in the type envts.
</p>
<p>
Since <tt>loadInterface</tt> does typechecking etc, it'd make sense for it to return a <tt>ModDetails</tt> instead and for that <tt>ModDetails</tt> to be stored in the EPS. This would also tidy up the oddity that a <tt>ModIface</tt> contains redundant fields for fixity envt and deprecaction envt (they would move to <tt>ModDetails</tt>).
</p>
<p>
Then it'd also make sense for the GHC API to use <tt>ModDetails</tt> instead of <tt>ModInfo</tt>.
</p>
<p>
This change isn't truly hard, but it needs care.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1631#changelog
http://ghc.haskell.org/trac/ghc/ticket/7790
http://ghc.haskell.org/trac/ghc/ticket/7790#7790: Add dummy undefined symbols to indicate waysSun, 24 Mar 2013 08:25:04 GMTezyang<p>
Currently, "way" information is not recorded into object files; it is only recorded into 'hi' files. This means if you are using, say, rts/Linker.c (say, if you're GHCi or a dynamic plugins package), if you mess up and load an object file compiled the wrong way, you will be very sad.
</p>
<p>
I think a cute trick we could play is to define a bunch of dummy symbols per-way, and add them as undefined symbols to objects, to indicate what way they were compiled, e.g. with the <tt>-u</tt> linker flag. Various RTS's export the symbols of ways they support, and attempting to link an object with an incompatible RTS results in a link error.
</p>
<p>
Are there any problems with this scheme? If not, I'll go ahead and implement it.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7790#changelog
http://ghc.haskell.org/trac/ghc/ticket/9403
http://ghc.haskell.org/trac/ghc/ticket/9403#9403: Make --show-iface more human readableSun, 03 Aug 2014 22:41:24 GMTezyang<p>
Right now --show-iface is not particularly interpretable, even if you are looking at the Outputable instance for <tt>ModIface</tt>. The problem seems to be the output for <tt>mi_deps</tt>, <tt>mi_usages</tt>, <tt>mi_decls</tt>, <tt>mi_insts</tt>, <tt>mi_fam_insts</tt> and <tt>mi_rules</tt> is not clearly delimited, making it unclear (for example) what <tt>import -/ base:Prelude HASH</tt> refers to unless you already happen to know that this must be from <tt>mi_usages</tt>.
</p>
<p>
It should be relatively easy to improve this, but I want to make sure people who rely on this output aren't blindsided by the changes.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9403#changelog
http://ghc.haskell.org/trac/ghc/ticket/9506
http://ghc.haskell.org/trac/ghc/ticket/9506#9506: Name libraries (dll/so) separately from linker symbolsSat, 23 Aug 2014 00:38:11 GMTezyang<p>
Tracking ticket so I don't forget. Based on feedback on <tt>#ghc</tt>, it sounds like it would be helpful if library names on the file system only had their full package name, e.g. <tt>libHScontainers_HASH.so</tt> as opposed to the abbreviated package name. Additionally, it seems less necessary to provide the abbreviated package name in linker symbols, since the modules often give a pretty good clue (and the package key can be looked up.) So let's do this, and make things better for users.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9506#changelog
http://ghc.haskell.org/trac/ghc/ticket/9805
http://ghc.haskell.org/trac/ghc/ticket/9805#9805: Use TrieMaps to speed up type class instance lookupMon, 17 Nov 2014 02:23:59 GMTezyang<p>
Currently, type class instance resolution is performed by doing a map lookup by type class, and then linearly matching against every instance. This is not great, and for a while, simonpj has been keen on using the TrieMap data structure in GHC, which has been previously used to implement a map from CoreExprs to various things (e.g. for CSE). What makes this a little tricky is that instance lookup isn't intended to be an exact match: we should unify so-called template variables and provide a substitution; furthermore, there may be multiple matches.
</p>
<p>
After some prototyping, I think we should be able to make this work. The primary refactoring we have to do is *maintain the key associated with an entry in a TrieMap*. Unlike the current uses of TrieMaps, where it's acceptable to lose the underlying key associated with an entry in the TrieMap, we need to know the key when doing unification, because it may be reported in the substitution. There are a few knock-on effects of this:
</p>
<ul><li>We should add a method <tt>foldWithKeyTM :: (Key m -> a -> b -> b) -> m a -> b -> b</tt> to the <tt>TrieMap</tt> type class.
</li><li>We need a variant of <tt>UniqFM</tt> which tracks the original key that was used. I propose we name it <tt>UniqKM</tt> (unique key map). A number of implementations of <tt>TrieMap</tt> need to be adjusted to use this instead of <tt>UniqFM</tt>.
</li><li>Why can't we just represent keyed TrieMaps as <tt>TypeMap (Type, a)</tt>? It might be possible. An insurmountable difficulty would be if we need to know the partial key PRIOR to having finished traversing the TrieMap; however, for the parts of the unification algorithm I've implemented, this does not seem to be the case. The primary actual difficulty is that <tt>Type</tt> uses a named representation, whereas <tt>TypeMap</tt> keys are on-the-fly deBruijn numbered. There would at least be some annoying fiddliness.
</li><li>Reversing the deBruijn numbered key into a <tt>Type</tt> is a bit goofy. Essentially, you need the reverse of the current <tt>CmEnv</tt>: a mapping from de Bruijn levels to the <tt>Var</tt> you've decided to allocate. (I've called this <tt>CfEnv</tt> in my prototype)
</li><li>When we represent a TrieMap binder, we have to put the binder map on the OUTSIDE, as opposed to the inside as it is currently. Otherwise, we can't update the <tt>CfEnv</tt> with the new mapping before making the recursive call to fold-with-key.
</li></ul><p>
I'll attach the standalone Haskell file I used to prototype this, wherein I copy-pasted a lot of Haskell from GHC's source and implemented fuzzy map on a simplified version of <tt>Type</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9805#changelog
http://ghc.haskell.org/trac/ghc/ticket/9706
http://ghc.haskell.org/trac/ghc/ticket/9706#9706: New block-structured heap organization for 64-bitMon, 20 Oct 2014 06:48:02 GMTezyang<p>
I was having some discussion about GHC's block structured heap with Sergio Benitez and Adam Belay, and during the discussion it was suggested that the way GHC manages the block structured heap is suboptimal when we're on 64-bit architectures.
</p>
<p>
At the moment, we allocate memory from the operating system per-megablock, storing metadata in the very first megablock. We have to do this because, on 32-bit, we can't generally be too picky about what address our memory ends up living. On 64-bits, we have a lot more flexibility.
</p>
<p>
Here is the proposal:
</p>
<ol><li>Statically decide on a maximum heap size in a power of two.
</li><li>Next, probe for some appropriately aligned chunk of available virtual address space for this. On POSIX, we can mmap /dev/null using PROT_NONE and MAP_NORESERVE. On Windows, we can use VirtualAlloc with MEM_RESERVE. (There are few other runtimes which do this trick, including GCC Go.)
</li><li>Divide this region into blocks as before. The maximum heap size is now the megablock size, and the block size is still the same as before. Masking to find the block descriptor works as before.
</li><li>To allocate, we keep track of the high-watermark, and mmap in 1MB pages as they are requested. We also keep track of how much metadata we need, and mmap extra pages to store metadata as necessary.
</li></ol><p>
We still want to request memory from the operating system in conveniently sized chunks, but we can now abolish the notion of a megablock and the megablock allocator, and work purely with block coalescing. Additionally, the recorded heap location means that we can check if a pointer is HEAP_ALLOCED using a mask and equality check, solving <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/8199" title="feature request: Get rid of HEAP_ALLOCED (new)">#8199</a>.
</p>
<p>
What do people think?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9706#changelog
http://ghc.haskell.org/trac/ghc/ticket/8597
http://ghc.haskell.org/trac/ghc/ticket/8597#8597: Git Hook script to prevent large binary blobs being checked inFri, 06 Dec 2013 10:19:45 GMThvr<p>
It has already occurred in the past in <tt>testsuite.git</tt> repo, that executables were checked in by accident, and caused the Git history to get bloated.
</p>
<p>
In order to avoid such accidents in the future a Git hook script in the style of <a class="ext-link" href="http://stackoverflow.com/questions/20226132/is-there-a-git-hook-which-can-prevent-binary-check-ins"><span class="icon"></span>this</a> might be useful, but taking also into account the size, and/or possibly with a magic safeword to be put in the commit message, to override the check for a single commit, if the author really knows what (s)he's doing.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8597#changelog
http://ghc.haskell.org/trac/ghc/ticket/9588
http://ghc.haskell.org/trac/ghc/ticket/9588#9588: Add `MonadPlus {IO,Either e}` and `Alternative (Either e)` instancesSat, 13 Sep 2014 13:27:56 GMThvr<p>
The following 3 instances are currently Orphans in <tt>transformers</tt> but shall be defined in <tt>base</tt> instead:
</p>
<div class="code"><pre><span class="kr">instance</span> <span class="kt">MonadPlus</span> <span class="kt">IO</span>
<span class="kr">instance</span> <span class="kt">MonadPlus</span> <span class="p">(</span><span class="kt">Either</span> e<span class="p">)</span>
<span class="kr">instance</span> <span class="kt">Alterantive</span> <span class="p">(</span><span class="kt">Either</span> e<span class="p">)</span>
</pre></div><p>
This proposal by SPJ already passed the CLC back in April and only needs implementing. I'll submit a patch shortly to Phab
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9588#changelog
http://ghc.haskell.org/trac/ghc/ticket/9710
http://ghc.haskell.org/trac/ghc/ticket/9710#9710: Clean up Trac versionsTue, 21 Oct 2014 16:29:59 GMTgoldfire<p>
The "Version" pull-down menu in Trac has no apparent ordering principle. This should be fixed.
</p>
<p>
Even better, scrap many of the very old versions, as they're unsupported, anyway. Thanks!
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9710#changelog
http://ghc.haskell.org/trac/ghc/ticket/8317
http://ghc.haskell.org/trac/ghc/ticket/8317#8317: Optimize tagToEnum# at Core levelTue, 17 Sep 2013 12:31:49 GMTjstolarek<p>
Old comparison primops that returned Bool were implemented by inserting call to <tt>tagToEnum#</tt> in the code generator. This call to <tt>tagToEnum#</tt> was later optimized away by a special case in the code geenrator (see <a href="/trac/ghc/browser/ghc/compiler/codeGen/StgCmmExpr.hs">compiler/codeGen/StgCmmExpr.hs</a>, Note [case on bool])). Now that we have new comparison primops (see <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/6135" title="feature request: Unboxed Booleans (closed: fixed)">#6135</a>) we no longer insert <tt>tagToEnum#</tt> in the code generator - all uses of <tt>tagToEnum#</tt> come from explicit calls in a source program. But we still have that special case in the code generator to optimize away <tt>tagToEnum#</tt>. We should drop that special case in the code generator and handle scrutinizing of <tt>tagToEnum#</tt> at the Core level by:
</p>
<ol><li>removing call to <tt>tagToEnum#</tt> in the scrutinee
</li><li>adding calls to <tt>dataToTag#</tt> in case branches
</li><li>constant-folding inserted <tt>dataToTag#</tt>
</li></ol><p>
Here is an example. This Haskell code:
</p>
<pre class="wiki">if tagToEnum# (a ># b)
then E1
else E2
</pre><p>
will be translated to this Core:
</p>
<pre class="wiki">case tagToEnum# (a ># b) of
True -> E1
False -> E2
</pre><p>
and optimized like this:
</p>
<pre class="wiki">case a ># b of
dataToTag# True -> E1
dataToTag# False -> E2
</pre><p>
====>
</p>
<pre class="wiki">case a ># b of
1 -> E1
0 -> E2
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8317#changelog
http://ghc.haskell.org/trac/ghc/ticket/2968
http://ghc.haskell.org/trac/ghc/ticket/2968#2968: Avoid generating C trigraphsTue, 20 Jan 2009 15:34:19 GMTduncan<pre class="wiki">main = print "??)"
</pre><p>
If we compile the above with an <tt>unregisterised</tt> ghc then some gcc versions report:
</p>
<pre class="wiki">/tmp/ghc6084_0/ghc6084_0.hc:99:30:
warning: trigraph ??) ignored, use -trigraphs to enable
</pre><p>
This should make us nervous.
</p>
<p>
According to the GCC manual if we were ever to use <tt>-std=c89</tt> or any of the official C standard compliance modes (ie non-GNU) then we would get standard C (cpp) trigraph behavior.
</p>
<p>
We should therefore add a codeGen/should_run test to make sure that the above program does always print <tt>"??)"</tt> and never <tt>"]"</tt>. This test only needs to be run in <tt>unregisterised</tt> mode.
</p>
<p>
It's not an immediate priority but it may trip someone up in future when porting or if we make unregisterised C code more standards compliant and start using one of the official <tt>-std=</tt> modes. It is unlikely to hit us but if it ever did it'd be a real pain to debug.
</p>
<p>
Edit: replaced <tt>-fvia-c</tt> by <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/Building/Unregisterised">unregisterised</a> (see <a class="changeset" href="http://ghc.haskell.org/trac/ghc/changeset/392b7e2a34d26b01ca65648eb5b4a078b0a64e69/ghc" title="Turn -vfia-C into a no-op">392b7e2a34d26b01ca65648eb5b4a078b0a64e69</a>).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2968#changelog
http://ghc.haskell.org/trac/ghc/ticket/3384
http://ghc.haskell.org/trac/ghc/ticket/3384#3384: Add HsSyn prettyprinter testsSun, 19 Jul 2009 20:00:48 GMTigloo<p>
Add HsSyn prettyprinter tests. See <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1966" title="task: Incorrect Outputable instance for InstDecl (closed: fixed)">#1966</a> for some discussion.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3384#changelog
http://ghc.haskell.org/trac/ghc/ticket/701
http://ghc.haskell.org/trac/ghc/ticket/701#701: Better CSE optimisationMon, 20 Feb 2006 13:58:05 GMTsimonmar<p>
GHC's CSE optimisation is pretty weedy. It looks for expressions like this:
</p>
<pre class="wiki"> let x = e1 in e2
</pre><p>
and replaces all occurrences of e1 in e2 with x. This doesn't do full CSE, but it does catch some cases. There have been case where full CSE would be significantly beneficial, though.
</p>
<p>
One possible way forward is to have a separate CSE pass that transformed expressions containing common subexpressions into the let-form above, and let the existing CSE pass do the final replacement.
</p>
<p>
We must be cautious, though: increasing sharing can introduce space leaks. Sometimes we can prove that this cannot happen, for example when the shared object is primitive, or has a bounded size.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/701#changelog
http://ghc.haskell.org/trac/ghc/ticket/8308
http://ghc.haskell.org/trac/ghc/ticket/8308#8308: Resurrect ticky code for counting constructor arityMon, 16 Sep 2013 09:37:56 GMTjstolarek<p>
There is a dead piece of ticky profiling code that computes histograms of data constructor arities (including tuples) and size of vector returns. The function responsible is <tt>bumpHistogram</tt> in <a href="/trac/ghc/browser/ghc/compiler/codeGen/StgCmmTicky.hs">compiler/codeGen/StgCmmTicky.hs</a>, which masks the commented out function <tt>bumpHistogramE</tt>. We can improve ticky profiling by resurrecting this dead code. There are following things that need to be done:
</p>
<ol><li>Replace current no-op <tt>bumpHistogram</tt> with <tt>bumpHistogramE</tt>. Note that current implementation of <tt>bumpHistogramE</tt> computes constructor arity at runtime. This is unnecessary because we know arity at compile time so we can avoid runtime check by doing sth like this:
</li></ol><pre class="wiki">bumpHistogram lbl n = do
let offset = n `min` 8
emit (addToMem cLong
(cmmIndexExpr cLongWidth
(CmmLit (CmmLabel (mkRtsDataLabel lbl)))
(CmmReg (CmmInt (fromIntegral offset) cLongWidth)))
1)
</pre><p>
Note that <tt>mkRtsDataLabel</tt> function does not exist anymore but we should be able to replace that call with <tt>mkCmmDataLabel rtsPackageId lbl</tt> (speculation).
</p>
<ol start="2"><li>We need to declare arrays that will store histogram values. Declarations of variables used for storing ticky statistics are in <a href="/trac/ghc/browser/ghc/includes/stg/Ticky.h">includes/stg/Ticky.h</a>. We also need to initialize the declared array to contain only zeros.
</li></ol><ol start="3"><li>Having declared the arrays we need to fix printing of computed arities. This is done in <a href="/trac/ghc/browser/ghc/rts/Ticky.c">rts/Ticky.c</a>. Note that there is a lot of code that is commented out (<tt>/* krc: comment out some of this stuff temporarily */</tt>) or disabled with <tt>#if FALSE</tt> pragma. We need to resurect *some* of it. There is a <tt>PR_HST</tt> macro for printing one histogram entry. This seems bad. We should probably rework the part of code responsible for printing out results of historgams.
</li></ol><ol start="4"><li>Current code counts arities from 0 to 8. Everything above 8 is put into the same bin as 8. This magical 8 is spread all over the code. We should declare a constant that is visible both in Haskell sources (see <tt>bumpHistogram</tt> in 1.) and RTS files and have all code behave properly depending on that constant - we should have loops instead of statically printing 9 elements of histogram array.
</li></ol><ol start="5"><li>Some ticky functions that count arity histograms are not used. For example <tt>tickyReturnNewCon</tt> should probably be called by <tt>cgConApp</tt> like this:
</li></ol><pre class="wiki"> ; emit =<< fcode_init
; tickyReturnNewCon
; emitReturn [idInfoToAmode idinfo] }
</pre><p>
The above is a an outline, which should be fairly accurate, but unexpected things may show up along the way.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8308#changelog
http://ghc.haskell.org/trac/ghc/ticket/1377
http://ghc.haskell.org/trac/ghc/ticket/1377#1377: GHCi debugger tasksFri, 25 May 2007 08:52:26 GMTsimonmar<p>
I'm collecting all these together into one ticket for now. Later we might split off individual tasks. Please update the description if you complete one of these.
</p>
<h2 id="easy">easy</h2>
<ul><li>Autocompletion for :break only provides names, not modules
</li></ul><h2 id="moderate">moderate</h2>
<ul><li>for each breakpoint we should retain the declpath constructed by the coverage pass. This would let us
show the enclosing binding(s) for each breakpoint in the UI (eg. "Stopped in M.f (M.hs:40:23-28)").
</li></ul><ul><li>:force should catch exceptions, so [1,2,undefined] would display as <tt>[1,2,< exception >]</tt>
</li></ul><ul><li>show variables with unboxed types.
</li></ul><ul><li>tabs go wrong with :list (but only for .lhs files, because unlit does tab expansion... duh)
</li></ul><h2 id="unknownorrequirethinkingabout">unknown, or require thinking about</h2>
<ul><li>Some kind of "step over" or "next" command is needed.
</li></ul><ul><li><tt>:break <qualified name></tt> only works if the name is exported can/should we relax this?
</li></ul><ul><li>perhaps we should have a :watch command, that could be used to save variables for future inspection (they wouldn't get
thrown away by :continue)
</li></ul><ul><li>We can disable a breakpoint with ":set stop N :continue", but this still prints out the breakpoint info when we stop.
Should we print the info only if there were no commands?
</li></ul><ul><li>Revert to adding tick information to the BCO directly, and remove the byte code instructions for breaks. I'm not sure that this is worth it. In some ways the implementation based on a byte code instruction is a little cleaner than adding breaks on BCOs directly. Though the bc instruction method may be a little slower than the other way.
</li></ul><ul><li>Flag to disable breakpoints?
</li></ul><ul><li>When we restore the interactive context on resume, we throw away any new bindings made since the breakpoint. Can this
be fixed?
</li></ul><ul><li>threads and breakpoints.
</li></ul><ul><li>if a :force results in a breakpoint, we should treat it as we do other evaluations. (currently we get
"<strong>* Ignoring breakpoint").
</strong></li></ul><p>
</p>
<ul><li>It's a bit strange that in "f = e" you don't get a breakpoint covering the whole binding, but in "f x = e" you do.
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1377#changelog
http://ghc.haskell.org/trac/ghc/ticket/9832
http://ghc.haskell.org/trac/ghc/ticket/9832#9832: Get rid of PERL dependency of `ghc-split`Mon, 24 Nov 2014 16:50:58 GMThvr<p>
The problem:
</p>
<p>
<tt>ghc-split</tt> is a ~280 SLOC (literate) Perl script and it's needed at runtime by GHC. Which means that we depend on a Perl interpreter, and since Windows usually doesn't have one installed by default, we need to bundle a Perl interpreter w/ the GHC binary Windows distribution for convenience.
</p>
<p>
Obvious solutions:
</p>
<ol><li>Rewrite <tt>ghc-split</tt> tool in Haskell, or
</li></ol><ol start="2"><li>Merge <tt>ghc-split</tt> functionality into GHC proper
</li></ol>Resultshttp://ghc.haskell.org/trac/ghc/ticket/9832#changelog
http://ghc.haskell.org/trac/ghc/ticket/609
http://ghc.haskell.org/trac/ghc/ticket/609#609: Useful optimisation for set-cost-centreWed, 02 Feb 2005 00:00:00 GMTsimonpj<p>
If you compile, for example, drvrun014 with -prof -auto-all, you'll see stuff like
</p>
<pre class="wiki"> (scc "c" (dataToTag#)) y
</pre><p>
This generates bad code, because we end up eta-expaning dataToTag, which allocates an extra function closure.
</p>
<p>
We think that in general
</p>
<pre class="wiki"> (scc "c" e) y = scc "c" (e y)
</pre><p>
to within a small constant factor. So maybe the simplifier, or <tt>CorePrep</tt>, or both, should do this transformation.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/609#changelog
http://ghc.haskell.org/trac/ghc/ticket/3462
http://ghc.haskell.org/trac/ghc/ticket/3462#3462: New codegen: allocate large objects using allocateLocal()Tue, 25 Aug 2009 08:48:42 GMTsimonmar<p>
See <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3424" title="bug: Corrupt executable when compiling large do block for List monad (closed: fixed)">#3424</a>.
</p>
<p>
In the new code generator, we should allocate large objects (larger than F * block size, for some suitable fraction F) using the RTS <tt>allocateLocal()</tt> API rather than from the nursery. It works to allocate them from the nursery -- this is what GHC 6.12 does after the fix in <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3424" title="bug: Corrupt executable when compiling large do block for List monad (closed: fixed)">#3424</a> -- but then they will not be treated as large objects and will be copied during GC. Also, the allocation is likely to fail, requiring a trip through the RTS to put a large enough block in the nursery to satisfy the allocation.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3462#changelog
http://ghc.haskell.org/trac/ghc/ticket/5143
http://ghc.haskell.org/trac/ghc/ticket/5143#5143: Soft heap limit flagWed, 20 Apr 2011 08:33:32 GMTsimonmar<p>
This came up in discussion on IRC yesterday. The <tt>+RTS -M<size></tt> flag does two things:
</p>
<ul><li>it starts tuning the GC to be more frugal as we get closer to <tt><size></tt>, by enabling in-place compaction and making major GC more frequent (reducing <tt>-F</tt> in effect).
</li></ul><ul><li>it stops the system with an out of memory error if memory usages gets too close to <tt><size></tt>
</li></ul><p>
The problem is often you want the first but not the second, because you'd like to say to the RTS "try to use no more than 2GB, because after that we're into swap space", but you don't want the program to fail if the limit is exceeded.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5143#changelog
http://ghc.haskell.org/trac/ghc/ticket/8785
http://ghc.haskell.org/trac/ghc/ticket/8785#8785: Replace hooks API in the RTS with something betterFri, 14 Feb 2014 08:40:25 GMTsimonmar<p>
Hooks rely on static linking behaviour which doesn't always work: we have to disable -Bsymbolic for the RTS on Linux (see <tt>compiler/main/SysTools.lhs</tt>) and it apparently doesn't work at all on Mac (<a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/8754" title="bug: :set +s always says space usage is 0 bytes (closed: fixed)">#8754</a>).
</p>
<p>
So instead of hooks we should be passing in information when we initialize the RTS, like we already do for some other things (<tt>-rtsopts</tt> etc.).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8785#changelog
http://ghc.haskell.org/trac/ghc/ticket/932
http://ghc.haskell.org/trac/ghc/ticket/932#932: Improve inliningWed, 11 Oct 2006 09:10:13 GMTsimonpj<p>
Currently the contruct
</p>
<pre class="wiki"> case (x# ># 0#) of ...
</pre><p>
attracts no argument discount for x#, which is silly.
</p>
<p>
The comment in CoreUnfold says:
</p>
<pre class="wiki"> PrimOpId op -> primOpSize op (valArgCount args)
-- foldr addSize (primOpSize op) (map arg_discount args)
-- At one time I tried giving an arg-discount if a primop
-- is applied to one of the function's arguments, but it's
-- not good. At the moment, any unlifted-type arg gets a
-- 'True' for 'yes I'm evald', so we collect the discount even
-- if we know nothing about it. And just having it in a primop
-- doesn't help at all if we don't know something more.
</pre><p>
But the right thing to do seems to be to fix interestingArg in SimplUtils so that it only thinks a primitive-typed thing is interesting if it knows its value (or some structure).
</p>
<p>
Here's the program that triggered this thought:
</p>
<pre class="wiki">import GHC.Word
import GHC.Base
import GHC.Prim
a `shiftRLT` b | b >=# 32# = int2Word# 0#
| otherwise = a `uncheckedShiftRL#` b
(W32# x#) `shift` (I# i#) =
{- we do an actual case analysis on i# to try to give us a discount -}
case i# of
{- For some bizzare reason removing the `shiftRLT` 0# makes the
inlining fail again -}
0# -> W32# (x# `shiftRLT` 0#)
_ ->
if i# >=# 0# then W32# (narrow32Word# (x# `shiftL#` i#))
else W32# (x# `shiftRLT` negateInt# i#)
x `shiftR` y = x `shift` (-y)
shift7 x = x `shiftR` 7
</pre><p>
roconnor@… initiated the thread
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/932#changelog
http://ghc.haskell.org/trac/ghc/ticket/4281
http://ghc.haskell.org/trac/ghc/ticket/4281#4281: Make impredicativity work properlyWed, 01 Sep 2010 11:44:08 GMTsimonpj<p>
This ticket is a placeholder for work on impredicativity. In fact, with the new typechecker we have most of the story for impredicativity in place, in the style of QML. Still missing are:
</p>
<ul><li>Rigid type signatures
</li><li>Notation for type application
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4281#changelog
http://ghc.haskell.org/trac/ghc/ticket/2123
http://ghc.haskell.org/trac/ghc/ticket/2123#2123: implement waitForProcess using signalsTue, 26 Feb 2008 10:34:13 GMTsimonmar<p>
<tt>waitForProcess</tt> currently calls <tt>waitpid</tt> with a safe FFI call, which means that
</p>
<ul><li>you need to use <tt>-threaded</tt> to call this in a multithreaded program
</li><li>one OS thread is needed per <tt>waitProcess</tt>
</li></ul><p>
instead we could implement this using the IO manager: have <tt>waitForProcess</tt> communicate with the IO manager, which wakes up the client when the appropriate <tt>SIGCHLD</tt> is received. Note that this means hooking <tt>SIGCHLD</tt> so we'd interact badly if the program itself wanted to use <tt>SIGCHLD</tt>.
</p>
<p>
I think it was Duncan Coutts who mentioned this idea to me.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2123#changelog
http://ghc.haskell.org/trac/ghc/ticket/9596
http://ghc.haskell.org/trac/ghc/ticket/9596#9596: Create monoidal category framework for arrow desugarerTue, 16 Sep 2014 03:43:38 GMTspacekitteh<p>
I'm going to put it into a GHC namespace (GHC.Arrows.Experimental, perhaps) and put instances for Arrow and such in there as well. In a later ticket I'll work on the desugarer, converting erverything into SMC combinators rather than Arrow combinators.
</p>
<p>
The basic design is <a class="ext-link" href="http://blog.spacekitteh.moe/posts/new-monoidal-cats.html"><span class="icon"></span>here</a>.
</p>
<p>
The current Arrow story is such a mess that makes it nearly unusable. Hopefully, by breaking it apart and making it more general, it will result in clearer code in both GHC and end-user code.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9596#changelog
http://ghc.haskell.org/trac/ghc/ticket/9543
http://ghc.haskell.org/trac/ghc/ticket/9543#9543: Testsuite driver: replace "extra_clean" by "git clean -X"Wed, 03 Sep 2014 09:11:37 GMTthomie<p>
When adding a new test that creates extra files, one also has to do some bookkeeping:
</p>
<ol><li>Supply an <tt>extra_clean</tt> argument to the test function in <tt>all.T</tt>.
</li><li>Add an entry in <tt>testsuite/.gitignore</tt>
</li></ol><p>
Step number 1 is often forgotten. Currently there are over 200 uncleaned files and directories left behind in the <tt>testsuite</tt>, after running <tt>validate</tt> and then <tt>make clean</tt> (checked with <tt>git clean -X -d -n | wc -l</tt>).
</p>
<p>
I propose to replace the functionality that <tt>extra_clean</tt> provides, namely to remove these extra files when one calls <tt>make clean</tt>, by doing the equivalent of <tt>git clean -X -d</tt>:
</p>
<pre class="wiki"> -X
Remove only files ignored by Git.
-d
Remove untracked directories in addition to untracked files. ...
</pre><p>
That is: use the information from the <tt>.ignore</tt> files to figure out which files to delete on <tt>make clean</tt>.
</p>
<p>
The advantages of making this change are:
</p>
<ol><li>Less manual bookkeeping, less work, less code
</li><li>A more thorough <tt>make clean</tt>
</li></ol><p>
Implementation detail: we can not just call <tt>git clean</tt> directly, since this should also work when we are not in a git directory (for example a build directory created with <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/Building/Using">lndir</a>).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9543#changelog
http://ghc.haskell.org/trac/ghc/ticket/10074
http://ghc.haskell.org/trac/ghc/ticket/10074#10074: Implement the 'Improved LLVM Backend' proposalMon, 09 Feb 2015 21:16:14 GMTthoughtpolice<p>
This is a meta ticket designed to reflect the current implementation status of the 'Improved LLVM Backend' proposal, documented here:
</p>
<p>
<a class="ext-link" href="https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend"><span class="icon"></span>https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/10074#changelog
http://ghc.haskell.org/trac/ghc/ticket/634
http://ghc.haskell.org/trac/ghc/ticket/634#634: Implement a more efficient TArrayThu, 15 Dec 2005 14:06:59 GMTanonymous<p>
<tt>Control.Concurrent.STM.TArray</tt> is implemented as an immutable array of TVars. This gives good parallelism, but isn't very efficient if you don't need that parallelism.
</p>
<p>
See: <a class="ext-link" href="http://www.haskell.org//pipermail/haskell-cafe/2005-December/012909.html"><span class="icon"></span>http://www.haskell.org//pipermail/haskell-cafe/2005-December/012909.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/634#changelog
http://ghc.haskell.org/trac/ghc/ticket/2437
http://ghc.haskell.org/trac/ghc/ticket/2437#2437: More accurate package dependenciesFri, 11 Jul 2008 08:52:49 GMTsimonmar<p>
The problem we want to solve here is that there is currently no distinction between compile-time package dependencies and link-time package dependencies. Often a compile-time dependency is also a link-time dependency, but there are two instances in which it might not be:
</p>
<ul><li>Template Haskell: some packages might be required for executing TH code at
compile-time, but the compiled code doesn't require those packages to be
linked in.
</li></ul><ul><li><a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/Annotations">Annotations</a>: we're considering allowing arbitrary attributes to be attached
to declarations, where the attributes are compile-time Haskell expressions.
The same issue as with TH crops up again here.
</li></ul><p>
Currently we figure out which packages to link by looking at the (transitive closure of the) imports. It would be better to look at the external references of the compiled code; some of the packages referred to by imports may not need to be linked.
</p>
<p>
Similarly, we should figure out the dependencies of a <tt></tt>package<tt></tt> by taking the union of the link-time dependencies of its compiled modules. This means a small changes to Cabal.
</p>
<p>
None of this is particularly hard, and doesn't need any changes to the interface file format or package database: we just record fewer package dependencies than before. The only tricky bit is traversing the code to figure out what the package dependencies should be.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2437#changelog
http://ghc.haskell.org/trac/ghc/ticket/8440
http://ghc.haskell.org/trac/ghc/ticket/8440#8440: Get rid of the remaining static flagsSat, 12 Oct 2013 06:18:18 GMTthoughtpolice<p>
On the heels of fixing <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/8276" title="bug: Building Haddock documentation panics with perf build on x86_64 Linux (new)">#8276</a>, we should get rid of the remaining static flags. For the remaining cases, there's no real reason they should be static, other than changing them is fairly invasive and will require some refactoring.
</p>
<p>
I'm making this a goal for 7.10, since we only have 5 flags left (and a lot of the changes for them are overlapping, so fixing one will probably go a ways towards fixing the others.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8440#changelog
http://ghc.haskell.org/trac/ghc/ticket/8552
http://ghc.haskell.org/trac/ghc/ticket/8552#8552: Rename StgArrWords to StgArrBytesThu, 21 Nov 2013 13:15:14 GMTTarrasch<p>
Since <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3800" title="bug: sizeofByteArray# returns allocated words, not requested length in bytes (closed: fixed)">#3800</a>, <tt>StgArrWords</tt> contains a certain number of words and not bytes. One can easily forget this and make programming mistakes. For example if you try to store the number of words in the <tt>bytes</tt> field, the garbage collector won't honor your decision. (I learned the hard way :))
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8552#changelog
http://ghc.haskell.org/trac/ghc/ticket/8723
http://ghc.haskell.org/trac/ghc/ticket/8723#8723: sdist should not have to build everythingSat, 01 Feb 2014 00:11:34 GMTnomeata<p>
It would be nice if instead of
</p>
<pre class="wiki">$ perl boot
$ ./configure
$ make
$ make sdist
</pre><p>
it would suffice to run
</p>
<pre class="wiki">$ perl boot
$ ./configure
$ make sdist
</pre><p>
and if that would not build more than necessary to generate the tarballs.
</p>
<p>
It would save time on the GHC-HEAD-Debian-Package-autobuilder that I am currently working on.
</p>
<p>
I might look into this bug eventually, but if someone else feels like doing it: Even better. (Difficulty estimated conservatively; might well be less than an hour, besides maybe waiting for test runs to finish :-))
</p>
<p>
Remember to update <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/MakingReleases">MakingReleases</a> and <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/Building/StandardTargets">Building/StandardTargets</a> if this is implemented.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8723#changelog
http://ghc.haskell.org/trac/ghc/ticket/8782
http://ghc.haskell.org/trac/ghc/ticket/8782#8782: Using GADT's to maintain invariant in GHC librariesThu, 13 Feb 2014 13:32:01 GMTIceland_jack<p>
I rewrote <tt>compiler/utils/OrdList.lhs</tt> using a GADT to preserve some invariants stated only in comments — an excellent chance for <tt>ghc</tt> to eat its own proverbial dog food I feel :)
</p>
<p>
The type signatures remain the same so it should be a drop-in replacement but it does use some GHC features that are too recent (closed type families in particular, the <tt>IsList</tt> instance can be removed) making it ineligible for inclusion I believe.
</p>
<p>
hvr on <tt>#ghc</tt> suggested that I submit a patch anyway and that it could be implemented at a later date (they said <tt>ghc</tt> must be able to be compiled by the last two previous major versions), if this is useful then I will translate <tt>Bag.hls</tt> which has the same invariants but more complicated functions.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8782#changelog
http://ghc.haskell.org/trac/ghc/ticket/8842
http://ghc.haskell.org/trac/ghc/ticket/8842#8842: Make sure msys2 builds non emulating binariesTue, 04 Mar 2014 06:15:52 GMTschyler<p>
I came across this in my own project.
</p>
<p>
MSys2 doesn't enter #ifdef blocks which test for _WIN32. Instead, it pretends to be Linux and has a set of headers which emulate things like mmap.
</p>
<p>
These emulation functions are really really slow -- in my personal tests about 10x slower than calling the WINAPI -- so this ticket is just a reminder (it may already be done) for someone to check that MSys2 builds things non-emulated in GHC.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8842#changelog
http://ghc.haskell.org/trac/ghc/ticket/8992
http://ghc.haskell.org/trac/ghc/ticket/8992#8992: Instructions for using gdb with GHC on WindowsSun, 13 Apr 2014 07:57:15 GMTezyang<p>
gdb remains a useful tool for debugging executables on Windows, but getting it setup can be tricky, since modern gdb requires Python, which means you will end up installing MSYS Python alongside native Python. Unfortunately, MSYS Python doesn't work with the test suite, so one is in the delicate situation where you want your path to have MSYS Python if you're running gdb, but Windows Python if you're running the test suite. While one can work around this with modest annoyance (the easiest thing I've found is to just uninstall gdb/python when I'm not using it), it would be better if we removed this friction in some way.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8992#changelog
http://ghc.haskell.org/trac/ghc/ticket/9131
http://ghc.haskell.org/trac/ghc/ticket/9131#9131: Experiment with a dedicated solver for CoercibleTue, 20 May 2014 22:07:13 GMTnomeata<p>
This is something that I might want to do some time; it should not distract us from working and improving the current design and implementation. But I think it should be explored.
</p>
<p>
Currently <tt>Coercible</tt> appears as a type class, we have instances to explain it, and use the existing solver to solve them. The last part sometimes causes problems:
</p>
<ul><li>the order the instances are tried matters, there might be dead ends (<a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/9117" title="bug: Coercible constraint solver misses one (closed: fixed)">#9117</a>)
</li><li>recursive newtypes are not handled as good as they could be.
</li></ul><p>
It would be worth exploring if a dedicated solver for <tt>Coercible</tt> constraints could solve these issues. It could replace the existing <tt>getCoercibleInst</tt>. Given a constraint <tt>Coercible s t</tt> it would solve it completely, do nothing or (and this is not planned out yet) return some sufficient and in some sense primitive constraint that should appear in inferred type signatures etc.
</p>
<p>
Ideally we could still explain <tt>Coercible</tt> in terms of the instances written in the ICFP’14 paper, and simply state „GHC will find a solution using these instances, if there are any.“ instead of „The usual solver is employed, it might run into dead ends (or not, hard to tell).“
</p>
<p>
When tackling this task, I should do something that I keep postponing (because I don’t like to admit my lack of knowlege about that) but I think is really important: What are the theoretical properties of solving <tt>Coercible</tt> constraints? Is it even decidable? Semi decidable? Are there existing standard algorithms? How does this relate to SMT solving? And why don’t I know these things...
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9131#changelog
http://ghc.haskell.org/trac/ghc/ticket/9133
http://ghc.haskell.org/trac/ghc/ticket/9133#9133: Improve parser error reporting in `ghc-pkg`Wed, 21 May 2014 13:29:13 GMThvr<p>
Here's what I was confronted recently due to a broken sandbox environment:
</p>
<pre class="wiki">$ cabal info parsec
cabal: ghc-pkg: Data.Binary.Get.runGet at position 9583: demandInput: not enough bytes
</pre><p>
The main problem is that this message is not very helpful (other than telling that <tt>ghc-pkg</tt> wasn't able to do something). Duncan told me, that the recent <tt>binary</tt> API now provides better facilities for error reporting. That could be used to improve the UI of <tt>ghc-pkg</tt> when reporting errors.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9133#changelog
http://ghc.haskell.org/trac/ghc/ticket/9331
http://ghc.haskell.org/trac/ghc/ticket/9331#9331: Release Cabal 1.22 before GHC 7.10 releaseFri, 18 Jul 2014 17:23:28 GMTezyang<p>
Just a tracking bug so we don't forget.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9331#changelog
http://ghc.haskell.org/trac/ghc/ticket/9374
http://ghc.haskell.org/trac/ghc/ticket/9374#9374: Investigate Static Argument TransformationMon, 28 Jul 2014 07:21:51 GMTjstolarek<p>
At the moment the Static Argument Transformation (SAT) optimisation is not run unless explicitly enabled with <tt>-fstatic-argument-transformation</tt>. There was a comment by Max Bolingbroke in DynFlags that said this (that comment is now removed and replaced with a reference to this ticket):
</p>
<pre class="wiki">Max writes: I think it's probably best not to enable SAT with -O2 for the
6.10 release. The version of SAT in HEAD at the moment doesn't incorporate
several improvements to the heuristics, and I'm concerned that without
those changes SAT will interfere with some attempts to write "high
performance Haskell", as we saw in some posts on Haskell-Cafe earlier
this year. In particular, the version in HEAD lacks the tail call
criterion, so many things that look like reasonable loops will be
turned into functions with extra (unneccesary) thunk creation.
</pre><p>
6.10 was a long time ago. Has anything changed since then? Does it make sense to enable that optimisation now? What are the mentioned heuristics and were they finally implemented? Does anyone know what Haskell-cafe posts does Max refer to?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9374#changelog
http://ghc.haskell.org/trac/ghc/ticket/9511
http://ghc.haskell.org/trac/ghc/ticket/9511#9511: Remove deprecated -fglasgow-exts from NoFib suiteSun, 24 Aug 2014 05:25:40 GMTdfeuer<p>
Someone on #ghc noted that replacing -fglasgow-exts with only the necessary options in each case may change compile times, which may be undesirable. I think a reasonable workaround would be to just put all the options on the command line, whether necessary or not. This will increase the time needed to parse the command lines, but presumably by a trivial amount.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9511#changelog
http://ghc.haskell.org/trac/ghc/ticket/9534
http://ghc.haskell.org/trac/ghc/ticket/9534#9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCBSun, 31 Aug 2014 23:18:10 GMTjrp<p>
The attached is an implementation of the floating point accuracy test described in <em>The Baleful Influence of Benchmarks</em> section of <a class="ext-link" href="http://www.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF"><span class="icon"></span>http://www.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF</a>
</p>
<pre class="wiki">Results for Float:
r = 4098.0 produces 12.0 and 12.0 sig. bits
r = 4098.25 fails: root 0.99989897 isn't at least 1 <<<<
r = 4097.004 produces 12.0 and 11.999298 sig. bits
:
Worst accuracy is 11.999298 sig. bits
:
Results for Double:
r = 4098.0 produces Infinity and Infinity sig. bits
r = 4098.25 produces Infinity and 53.0 sig. bits
r = 4097.00390625 produces Infinity and 53.451178091541244 sig. bits
r = 1.6777218e7 produces Infinity and Infinity sig. bits
r = 1.677721825e7 produces Infinity and 75.0 sig. bits
r = 1.6777219e7 produces Infinity and 71.0 sig. bits
r = 9.4906267e7 produces 26.499999994288153 and 26.499999986733027 sig. bits
r = 9.490626725e7 fails: root 0.999999995635551 isn't at least 1 <<<
r = 2.684354505e8 produces 28.0 and 27.999999919383132 sig. bits
r = 2.684354515e8 produces 28.0 and 27.99999993013205 sig. bits
r = 2.68435458e8 produces 28.0 and 28.0 sig. bits
r = 2.6843545825e8 produces 28.0 and 28.00000000268723 sig. bits
r = 2.6843545700000006e8 produces 28.0 and 27.999999989251084 sig. bits
r = 4.294967298e9 produces 32.0 and 32.0 sig. bits
r = 4.29496729825e9 produces 32.0 and 32.00000000016795 sig. bits
Worst accuracy is 26.499999986733027 sig. bits
</pre><p>
This seems to be comparable to a clang version, but seems to be fairly poor in comparison to some other machines, back in the day (1997).
</p>
<p>
<strong>The attached could, possibly be turned into a testsuite test, by removing the QuickCheck tests that are included.</strong>
</p>
<p>
Observations:
</p>
<ul><li>There are a couple of failures (could be the implementation of sqrt or log).
</li><li>signum seems incorrect (signum Nan = -1.0)
</li><li>The prelude should have a copysign function
</li><li>min fails to produce the other argument if one argument is NaN
</li><li>The CFloat and CDouble variants seem to produce the same result as the native Float and Double versions
</li><li>The Haskell coding style could be improved to remove some boilerplate, make the code more idiomatic
</li><li>There may be a better way of entering the test values of r to ensure that they are accurate
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/9534#changelog
http://ghc.haskell.org/trac/ghc/ticket/9665
http://ghc.haskell.org/trac/ghc/ticket/9665#9665: Add "since" information to LANGUAGE extensions in GHC user guideSat, 04 Oct 2014 18:08:18 GMTandreas.abel<p>
If one wants to support older versions of GHC, it is hard to find out whether one can use a certain LANGUAGE extension. One has to go to older versions of the GHC manual to find out whether the corresponding documentation was already there, or browse release notes. Requests:
</p>
<ol><li>Document for new LANGUAGE extensions that they are available since version 7.10. For example, by adding "(Since GHC 7.10)" to the heading of the new feature.
</li></ol><ol start="2"><li>Do this also for the previous LANGUAGE extensions, by adding e.g., "(Since GHC 7.6)" etc.
</li></ol>Resultshttp://ghc.haskell.org/trac/ghc/ticket/9665#changelog
http://ghc.haskell.org/trac/ghc/ticket/9719
http://ghc.haskell.org/trac/ghc/ticket/9719#9719: Improve `mkInteger` interfaceFri, 24 Oct 2014 08:44:21 GMThvr<p>
<tt>mkInteger</tt> is the current operation provided by the <tt>Integer</tt> libraries to construct (large) integer values. The current type-signature is
</p>
<div class="code"><pre><span class="nf">mkInteger</span> <span class="ow">::</span> <span class="kt">Bool</span> <span class="c1">-- sign-bit</span>
<span class="ow">-></span> <span class="p">[</span><span class="kt">Int</span><span class="p">]</span> <span class="c1">-- absolute value in 31 bit chunks, least significant first</span>
<span class="ow">-></span> <span class="kt">Integer</span>
</pre></div><p>
A somewhat pathological example of why this representation is not so nice is the following simple CAF
</p>
<div class="code"><pre><span class="nf">c</span> <span class="ow">::</span> <span class="kt">Integer</span>
<span class="nf">c</span> <span class="ow">=</span> <span class="mh">0xf000000000000000</span>
</pre></div><p>
that (this is for a 64bit arch!) gets compiled into the following STG:
</p>
<pre class="wiki">==================== STG syntax: ====================
sat_sJQ :: GHC.Types.Int
[LclId, Str=DmdType] =
NO_CCS GHC.Types.I#! [3];
sat_sJR :: [GHC.Types.Int]
[LclId, Str=DmdType] =
NO_CCS :! [sat_sJQ GHC.Types.[]];
sat_sJP :: GHC.Types.Int
[LclId, Str=DmdType] =
NO_CCS GHC.Types.I#! [1610612736];
sat_sJS :: [GHC.Types.Int]
[LclId, Str=DmdType] =
NO_CCS :! [sat_sJP sat_sJR];
sat_sJO :: GHC.Types.Int
[LclId, Str=DmdType] =
NO_CCS GHC.Types.I#! [0];
sat_sJT :: [GHC.Types.Int]
[LclId, Str=DmdType] =
NO_CCS :! [sat_sJO sat_sJS];
Foo.c :: GHC.Integer.Type.Integer
[GblId, Str=DmdType] =
\u srt:SRT:[0Y :-> GHC.Integer.Type.mkInteger, sJT :-> sat_sJT] []
GHC.Integer.Type.mkInteger GHC.Types.True sat_sJT;
</pre><p>
Moreover, determining how much space to allocate for the resulting <tt>Integer</tt> is a bit work as it for one, you need to traverse the list twice, and then you can't simply derive the exact allocation amount by the list-length alone due to the odd 31-bit chunks.
</p>
<p>
Instead a more "natural" <tt>mkInteger</tt> would be desirable, possibly in the style of <tt>unpackCString#</tt>, in terms of a packed/unboxed vector of machine-word-sized chunks. A better <tt>mkInteger</tt> could then take a <tt>ByteArray#</tt> or a <tt>Addr#</tt> + length instead, e.g.
</p>
<div class="code"><pre><span class="nf">mkInteger</span> <span class="ow">::</span> <span class="kt">Int</span><span class="o">#</span> <span class="c1">-- signum(n) = sign of encoded Integer </span>
<span class="c1">-- abs(n) = number of machine-word sized chunks</span>
<span class="ow">-></span> <span class="kt">Addr</span><span class="o">#</span> <span class="c1">-- pointer to start of machine-word sized chunks, </span>
<span class="c1">-- least-significant chunk first</span>
<span class="ow">-></span> <span class="kt">Integer</span>
</pre></div>Resultshttp://ghc.haskell.org/trac/ghc/ticket/9719#changelog
http://ghc.haskell.org/trac/ghc/ticket/9735
http://ghc.haskell.org/trac/ghc/ticket/9735#9735: Template Haskell for cross compilers (port from GHCJS)Tue, 28 Oct 2014 15:27:55 GMTluite<p>
GHCJS supports Template Haskell by running it outside the compiler's process, with a different implementation of the Quasi type class. This can be done for other cross compilers too, if GHC gets an option to serialize Template Haskell requests and pass them to an external process.
</p>
<p>
Someone started the work on this, but I think he stopped. I still have a document with a step by step plan to build an iOS cross compiler, with pointers to the relevant GHC and GHCJS code.
</p>
<p>
<a class="ext-link" href="https://github.com/ghcjs/ghcjs/wiki/Porting-GHCJS-Template-Haskell-to-GHC"><span class="icon"></span>https://github.com/ghcjs/ghcjs/wiki/Porting-GHCJS-Template-Haskell-to-GHC</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9735#changelog
http://ghc.haskell.org/trac/ghc/ticket/9758
http://ghc.haskell.org/trac/ghc/ticket/9758#9758: By default, testsuite should clean up after successful testsMon, 03 Nov 2014 09:28:27 GMTezyang<p>
A fully built GHC compiler for development takes about 1G of space. However, running the testsuite balloons this amount to 10G. Why? Because we don't clear away any test files by default.
</p>
<p>
Now, it's pretty useful to have these files if you're debugging a problem. But I think it's pretty unnecessary for successful tests. So I suggest cleaning out the files automatically if the test succeeds.
</p>
<p>
Tradeoff: the testsuite will take longer to run since it is cleaning up after itself.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9758#changelog
http://ghc.haskell.org/trac/ghc/ticket/9786
http://ghc.haskell.org/trac/ghc/ticket/9786#9786: Make quot/rem/div/mod with known divisors fastMon, 10 Nov 2014 01:06:31 GMTdfeuer<p>
GHC (with NCG) currently optimizes <tt>Int</tt> division by powers of two, but not by other known divisors. The Intel Optimization Manual section 9.2.4 describes a general technique for replacing division by known, sufficiently small, divisors with multiplication. LLVM appears to go further in some fashion. There's no reason we can't do something similar.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9786#changelog
http://ghc.haskell.org/trac/ghc/ticket/9837
http://ghc.haskell.org/trac/ghc/ticket/9837#9837: Introduce a logging API to GHCWed, 26 Nov 2014 14:14:13 GMTrodlogic<p>
I don't have a lot of mileage with the code base, but I do see that there is no standard logging API that the various components can use (or there is and it just needs to be used??).
</p>
<p>
At least, I would expect to see a standard API to generate log entries with the following minimal parts:
</p>
<ul><li>timestamp
</li><li>Log level - for example, ERROR, WARN, INFO, DEBUG, TRACE (-v<a class="source" href="http://ghc.haskell.org/trac/ghc/log/ghc/?revs=1-3">[1-3]</a> could map to INFO, DEBUG and TRACE. Log levels are inclusive so INFO also means WARN and ERROR.
</li><li>Component name - so we know what is the source of the log message. At least I would expect to see (Desugarer, Typechecker, Parser, etc)
</li><li>the message
</li></ul><p>
It would also mean a single back-end to collect the log messages and dump them to a file, stdout/stderr, etc. There are many other features beyond this point (customize log messages, colors, filtering, etc), but in terms of the API that is used throughout the code base, it should be simple.
</p>
<p>
Was this already discussed in the past? Is there already such an API in the codebase? Is there an existing library that we could use to achieve the same? Any other ideas?
</p>
<p>
This ticket is mostly to spawn a discussion about it.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9837#changelog
http://ghc.haskell.org/trac/ghc/ticket/10137
http://ghc.haskell.org/trac/ghc/ticket/10137#10137: Rewrite switch code generationWed, 04 Mar 2015 16:30:44 GMTnomeata<p>
Inspired by <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/10124" title="bug: Simple case analyses generate too many branches (new)">#10124</a> I looked at the code generation for enumeration and integer types, and I think this can be improved in a few ways. My goals are:
</p>
<ul><li>Fancier code for integer types. Currently, the code for enumeration types will emit jump tables for dense choices; there is no reason to treat integer types differently.
</li><li>The ability to behave differently if some of the cases are equal, and, as an extension of that,
</li><li>The possibility to create branchless code if multiple checks would go to the same jump.
</li></ul><p>
The current scheme is roughly:
</p>
<ul><li>When we generate Cmm code for a STG case expression, we handle enumeration types and literals separately.
</li><li>At this point, the decisions about what code to generate are made (jump tables (but only for enumeration types) or if-then-else trees).
</li><li>The Common Block Optimization on Cmm happens later in the pipeline, making it non-trivial to detect branches that do the same thing.
</li></ul><p>
My plan is the following:
</p>
<ul><li>In the STG→Cmm transformation, floats will be handled separately. Matching against literals literals is fishy anyways, so my suggestion is to simply generate a linear list of equality checks here – turning the intended operation (equality test) into something else (comparisons in a if-then-else tree) feels wrong to me for floats. And the rest would not work well for floats, so I’d like to have them out of the way.
</li><li>The case of enumeration types will be reduced to word literals, and treated the same from now on.
</li><li>For integer types, no code generation decisions is made at this point. Instead, always a <tt>CmmSwitch</tt> statement is generated.
</li><li>In a separate Cmm transformation pass, which will run /after/ the common block optimization, we visit all <tt>CmmSwitches</tt> and create proper code for them.
</li></ul><p>
I’d like to separate the algorithm that plans the code generation into a function (possibly even module) of its own, so that the decisions can easily by analyized and modified.
</p>
<p>
The algorithm has a few choices to make:
</p>
<ul><li>If multiple values point to the same code, we can generate branchless code (<tt>y := x == 1 || x == 5 || x = 7; if (y==0) then goto l1 else goto l2</tt>).
</li><li>If there are whole ranges pointing to the same code, the above can also use comparisons.
</li><li>If there are dense ranges (i.e. a range with more than half of the possible values mapped to something), we want to generate jump tables from them (still <tt>CmmSwitch</tt> values).
</li><li>Unless all options are handled by one of these possibilities, they need to be combined using <tt>if-then-else</tt> trees.
</li></ul><p>
The <tt>CmmSwitch</tt> constructor needs to change for that. It currently takes a <tt>[Maybe Label]</tt> argument, which is not suitable for before that pass, when its table may be sparse. I think an <tt>IntMap Label</tt> would work nicely.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/10137#changelog
http://ghc.haskell.org/trac/ghc/ticket/595
http://ghc.haskell.org/trac/ghc/ticket/595#595: Overhaul GHC's overlapping/non-exhaustive pattern checkingWed, 17 Sep 2003 00:00:00 GMTsimonmar<p>
GHC has a module in the desugarer (Check) which checks whether patterns are overlapping and/or exhaustive, to support the flags -fwarn-overlapping-patterns and -fwarn-non-exhaustive-patterns. The code is old and crufty, and has several outstanding bugs. A rewrite is needed.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/595#changelog
http://ghc.haskell.org/trac/ghc/ticket/597
http://ghc.haskell.org/trac/ghc/ticket/597#597: Various error messages have inaccurate source locationsWed, 12 May 2004 00:00:00 GMTsimonmar<p>
Some error messages lack source location information, or have inaccurate locations. Here are the ones we know about:
</p>
<ul><li>Should point to the import decl:
<pre class="wiki"> ShowFunctions.hs:1:0
Warning: Module `Text.Show.Functions' is imported, but nothing from it is used
</pre></li><li>Should point to the instance header:
<pre class="wiki"> mod41.hs:3:0:
Illegal instance declaration for `Eq (Either a a)'
(The instance type must be of form (T a b c)
</pre></li><li>Should point to 'deriving *Eq*', not the tycon:
<pre class="wiki"> tcfail046.hs:9:8:
No instance for `Eq (Pid -> Time -> Message a -> (MessList a, Continuation a
))'
When deriving the `Eq' instance for type `Continuation'
</pre></li><li>check_tau_type doesn't have location info?
<pre class="wiki"> tcfail100.hs:7:0:
Type synonym `A' should have 1 argument, but has been given 0
In the type synonym declaration for `B'
</pre></li><li>Location in LHsModule from the parser should really span the whole file, rather than a point span at (1,0).
</li></ul><ul><li>read016: should be the lhs only?
</li><li>tcfail044: should be the instance head only.
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/597#changelog
http://ghc.haskell.org/trac/ghc/ticket/599
http://ghc.haskell.org/trac/ghc/ticket/599#599: The Front PanelWed, 12 May 2004 00:00:00 GMTsimonmar<p>
GHC's runtime has a "front panel" which displays graphical representations of parts of the runtime as a program runs. For example, it shows the amount of data in each generation, how many threads there are, the memory layout, etc.
</p>
<p>
This was a quick hack, and there are many ways in which it could be extended to become a generally useful tool.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/599#changelog
http://ghc.haskell.org/trac/ghc/ticket/602
http://ghc.haskell.org/trac/ghc/ticket/602#602: Warning SuppressionThu, 01 Jul 2004 00:00:00 GMTsimonmar<p>
It should be possible to suppress particular kinds of warnings for parts of a source file.
</p>
<p>
One way to achieve this is to allow parts of a file to be delimited by pragmas specifying the warnings to be suppressed, and then filter out the warnings during compilation based on the source location attached to the warning.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/602#changelog
http://ghc.haskell.org/trac/ghc/ticket/603
http://ghc.haskell.org/trac/ghc/ticket/603#603: GC-spy connectionThu, 01 Jul 2004 00:00:00 GMTsimonmar<p>
Connect GHC's garbage collector to the <a class="ext-link" href="http://research.sun.com/projects/gcspy/"><span class="icon"></span>GC spy tool</a>, which gives a graphical display of heap characteristics at runtime.
</p>
<p>
(Similar to the Front Panel task: <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/599" title="task: The Front Panel (new)">599</a>.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/603#changelog
http://ghc.haskell.org/trac/ghc/ticket/605
http://ghc.haskell.org/trac/ghc/ticket/605#605: Optimisation: strict enumerationsWed, 06 Oct 2004 00:00:00 GMTsimonmar<p>
Strict enumeration types should be implemented by <tt>Int#</tt>, both in the strictness analyser and for constructor fields annotated with <tt>{-# UNPACK #-}</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/605#changelog
http://ghc.haskell.org/trac/ghc/ticket/618
http://ghc.haskell.org/trac/ghc/ticket/618#618: Dependency caching in ghc --makeSat, 05 May 2001 00:00:00 GMTsimonmar<p>
ghc --make should cache dependencies between runs, somehow.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/618#changelog
http://ghc.haskell.org/trac/ghc/ticket/624
http://ghc.haskell.org/trac/ghc/ticket/624#624: Program location for thread error messagesSun, 03 Jun 2001 00:00:00 GMTchak<p>
In programs with a substantial number of threads, the error messages like "indefinitely blocked" are not very helpful, because there is no indication as to which thread blocked. Having the source location of the 'fork' or so, would be much more helpful.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/624#changelog
http://ghc.haskell.org/trac/ghc/ticket/855
http://ghc.haskell.org/trac/ghc/ticket/855#855: Improvements to SpecConstrWed, 09 Aug 2006 12:10:07 GMTsimonpj<p>
There are a series of possible improvemnts to <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/SpecConstr">SpecConstr</a>, described in
the source code. <tt>compiler/specialise/SpecConstr</tt>
</p>
<ul><li> Specialising for constant parameters
</li><li>Specialising for lambda parameters
</li><li>Two ideas to do with strictness that look more tricky
</li></ul><p>
Some of them look quite straightforward.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/855#changelog
http://ghc.haskell.org/trac/ghc/ticket/888
http://ghc.haskell.org/trac/ghc/ticket/888#888: Implement the static argument transformationMon, 04 Sep 2006 16:37:57 GMTsimonpj<p>
The Static Argument transformation optimises
</p>
<pre class="wiki"> f x y = ....f x' y...
</pre><p>
into
</p>
<pre class="wiki"> f x y = let g x = ....g x'...
in g x
</pre><p>
Instead of passing <tt>y</tt> along unchanged, we make it into a free variable of a local function definition <tt>g</tt>.
</p>
<p>
Unfortunately, it's not always a win. Andre Santos gives a discussion, and quite a few numbers in <a class="ext-link" href="http://research.microsoft.com/%7Esimonpj/Papers/santos-thesis.ps.gz"><span class="icon"></span>his thesis</a>.
</p>
<p>
But sometimes it is a pretty big win. Here's the example that recently motivated me, which Roman Leshchinskiy showed me. You need the attached file Stream.hs, and then try compiling
</p>
<pre class="wiki"> import Stream
foo :: (a -> b) -> [a] -> [c]
foo f = mapL f
</pre><p>
Thus inspired, I think I have a set of criteria that would make the static arg transformation into a guaranteed win:
</p>
<ul><li>there is only one (external) call to the function
</li><li>OR its RHS is small enough to inline
</li><li>OR it is marked INLINE (?)
</li></ul><p>
So I'd like to try this idea out.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/888#changelog
http://ghc.haskell.org/trac/ghc/ticket/1009
http://ghc.haskell.org/trac/ghc/ticket/1009#1009: GHC Performance IndexFri, 17 Nov 2006 14:11:40 GMTsimonmar<p>
We want a lightweight way to detect when either (a) the compiler's performance changes, or (b) the performance of compiled code changes. This was triggerred by my noticing that the HEAD nightly builds seem somewhat slower than usual right now.
</p>
<p>
So the idea is pretty simple. We decide on a fixed set of nofib programs --intiially all of them, but we want the set to remain stable in the future -- and as part of the nightly build we time how long it takes to compile this set with a fixed set of flags (probably -O -fasm, to rule out changes in gcc). Then we time how long it takes to run all those programs, maybe 5 times each. Then we keep track of these two figures for every successful nightly build, and plot the results, giving us a nice way to track GHC's performance over time. We can go back and get some historical figures too. Of course the results are specific to a particular machine, so we'd have to keep track of results per nightly build machine or something.
</p>
<p>
So basically: some small changes to nofib to allow "just build everything" (I think even NoFibRuns=0 might do this), and to build a fixed set of programs (the set could be built into the nofib build system, no need to make it dynamic). And some way to collect the results and plot graphs.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1009#changelog
http://ghc.haskell.org/trac/ghc/ticket/1016
http://ghc.haskell.org/trac/ghc/ticket/1016#1016: Avoidance of unaligned loads is overly conservativeMon, 20 Nov 2006 16:08:12 GMTigloo<p>
On alpha, mips, mipsel and arm we do loads in a way that is safe even if they are unaligned (see <tt>cLoad</tt> in <tt>compiler/cmm/PprC.hs</tt>). We need this when, for example, we read things with <tt>indexInt16OffAddr#</tt> from <tt>Addr#</tt>s in alex-generated lexers, but most of the time we know that the address is aligned appropriately so loads are slower than they need be.
</p>
<p>
A better way to do this would be to make Load a <tt>MachOp</tt> parameterised by whether it's known to be aligned or not. Likewise, Store should be a <tt>CallishMachOp</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1016#changelog
http://ghc.haskell.org/trac/ghc/ticket/1349
http://ghc.haskell.org/trac/ghc/ticket/1349#1349: Generalise the ! and UNPACK mechanism for data types, to unpack function argumentsFri, 11 May 2007 12:51:40 GMTsimonpj<p>
See this thread:
</p>
<blockquote>
<p>
<a class="ext-link" href="http://www.nabble.com/More-speed-please!-t3411977.html"><span class="icon"></span>http://www.nabble.com/More-speed-please!-t3411977.html</a>
</p>
</blockquote>
<p>
Briefly the idea is to allow
</p>
<pre class="wiki"> data T = MkT (!Int -> Bool)
</pre><p>
to make a <tt>MkT</tt> hold strict functions only. Anyone unpacking a <tt>MkT</tt> can assume the function is strict; and anyone building a <tt>MkT</tt> gets a strictness wrapper aound whatever function they supply, so even if they supply a lazy function, it's made strict.
</p>
<p>
Seems like a natural generalisation of the existing strictness and UNPACK mechanism for data types.
</p>
<p>
Lots of details in the thread above.
</p>
<p>
Simon
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1349#changelog
http://ghc.haskell.org/trac/ghc/ticket/1371
http://ghc.haskell.org/trac/ghc/ticket/1371#1371: Add -O3Tue, 22 May 2007 08:16:19 GMTsimonmar<p>
It has been suggested that we should have an -O3 that trades off code size for speed. Things that we could do include bumping the threshold for some optimisations (inlining, <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/SpecConstr">SpecConstr</a>, LiberateCase), and perhaps inlining some operations in the back-end.
</p>
<p>
Of course we should measure the effect of various settings on nofib/nobench and pick a good combination.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1371#changelog
http://ghc.haskell.org/trac/ghc/ticket/1405
http://ghc.haskell.org/trac/ghc/ticket/1405#1405: Make ghc (stage1) be compilable by non-GHCFri, 01 Jun 2007 21:04:04 GMTIsaac Dupree<p>
This depends a bit on the existence of a good-enough non-GHC compiler. Possibility to do recursively dependent modules (I think) presently rules out everything except JHC, which is not entirely working yet. Also pattern guards might need to be implemented in that compiler. Maybe for testing, a ghc that doesn't define <span class="underline">GLASGOW_HASKELL</span> (and doesn't use ghc-specific flags ?? possibly a wrapper script of some sort) could be used too.
</p>
<p>
See <a class="ext-link" href="http://thread.gmane.org/gmane.comp.lang.haskell.cvs.ghc/20962"><span class="icon"></span>http://thread.gmane.org/gmane.comp.lang.haskell.cvs.ghc/20962</a> ... GHC also uses things like IORefs, (unsafeCoerce? only in stage2 I think) that everyone provides, but would still be good to document.
</p>
<p>
I'm working on this now, we'll see how far I get --Isaac
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1405#changelog
http://ghc.haskell.org/trac/ghc/ticket/1572
http://ghc.haskell.org/trac/ghc/ticket/1572#1572: Make it easy to find documentation for GHC and installed packagesWed, 01 Aug 2007 09:58:10 GMTsimonpj<p>
<tt>ghc-pkg</tt> builds a package database that helps GHC find all installed packages. But it'd be a great improment if the same step also helped the <strong>user</strong> find the Haddock documentation for all installed packages.
</p>
<p>
Corresponding to GHC's package database would be an HTML page that is a single point of entry for the user to find documentation about installed packages. Preferably together with a consolidated index. (And maybe <tt>ghc --help</tt> should give the local URL of this documentation root.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1572#changelog
http://ghc.haskell.org/trac/ghc/ticket/1600
http://ghc.haskell.org/trac/ghc/ticket/1600#1600: Optimisation: CPR the results of IOWed, 08 Aug 2007 10:28:40 GMTsimonmar<p>
GHC currently cannot unbox the result of a function in the IO monad. For example:
</p>
<pre class="wiki">facIO :: Int -> IO Int
facIO n = if n < 2 then return 1 else do n' <- facIO (n-1); return (n*n')
</pre><p>
the <tt>Int</tt> argument is unboxed fine, but not the result. It ought to be possible to do this: the CPR analysis needs to somehow look inside the unboxed pair returned by IO-monadic code.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1600#changelog
http://ghc.haskell.org/trac/ghc/ticket/1880
http://ghc.haskell.org/trac/ghc/ticket/1880#1880: Unify flag descriptions to generate both docs and codeMon, 12 Nov 2007 15:59:23 GMTsimonmar<p>
We want to specify all of GHC's flags in one place, and from there
</p>
<ul><li>Generate the flag reference section of the documentation
</li><li>Generate the code to parse the command-line
</li><li>Allow flags to be deprecated, generating a warning
</li><li>Have an option to list all the flags that GHC supports (see <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1226" title="feature request: Add flags --full-flag-help and --print-docdir (closed: duplicate)">#1226</a>)
for use in command-line completion
</li><li>Generate the man page
</li><li>Completion in GHCi
</li></ul><p>
This ticket replaces part of <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1226" title="feature request: Add flags --full-flag-help and --print-docdir (closed: duplicate)">#1226</a>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1880#changelog
http://ghc.haskell.org/trac/ghc/ticket/3024
http://ghc.haskell.org/trac/ghc/ticket/3024#3024: Rewrite hp2ps in HaskellThu, 12 Feb 2009 14:52:16 GMTSamB<p>
Right now, hp2ps is written in rather difficult to modify C, and is quite inflexible. We should rewrite it in Haskell and make it, among other things, more tolerant to incomplete records.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3024#changelog
http://ghc.haskell.org/trac/ghc/ticket/3251
http://ghc.haskell.org/trac/ghc/ticket/3251#3251: split rts headers into public and privateThu, 21 May 2009 12:29:24 GMTduncan<p>
C code calling into the rts, eg to initialise it, uses header files like <tt>HsFFI.h</tt> or <tt>RtsAPI.h</tt>. However these header files that describe the public API of the rts are installed in <tt>$libdir/ghc-x.y/include</tt> where as the standard location for public header files should be <tt>$prefix/include/ghc-x.y</tt>.
</p>
<p>
The private header files that are only used by <tt>.hc</tt> files when compiling <tt>-fvia-C</tt> should remain where they are. So this would involve identifying which headers are public and which are private.
</p>
<p>
Once we have a set of public header files it might be nice to provide a <tt>pkg-config</tt> .pc file to make it easy for C programs to locate the header files and libraries. Eg it should be possible to compile and link a C program that uses the RTS public API with just:
</p>
<pre class="wiki">gcc -o main main.c `pkg-config --cflags --libs ghc-rts-6.12.1`
</pre><p>
and this would supply the flags like
</p>
<pre class="wiki">-I/usr/include/ghc-6.12.1 -lHSrts -L/usr/lib/ghc-6.12.1
</pre><p>
Note that <tt>pkg-config</tt> supports both shared and static libs (ie allows specifying the extra private deps of a static lib, eg <tt>-lm -ldl</tt> etc).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3251#changelog
http://ghc.haskell.org/trac/ghc/ticket/3355
http://ghc.haskell.org/trac/ghc/ticket/3355#3355: Refactor Template Haskell syntax conversionsMon, 06 Jul 2009 08:55:37 GMTsimonmar<p>
On <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Conversions">TemplateHaskell/Conversions</a> there is a proposed refactoring of the Tempate Haskell-related syntax conversions. This task is to do that refactoring.
</p>
<p>
Edit: link.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3355#changelog
http://ghc.haskell.org/trac/ghc/ticket/3379
http://ghc.haskell.org/trac/ghc/ticket/3379#3379: GHC should use the standard binary packageFri, 17 Jul 2009 23:11:12 GMTigloo<p>
GHC should use the standard binary package, rather than reimplementing its functionality itself. If the current binary package is slower than GHC's Binary, then we should fix that.
</p>
<p>
There's some discussion about this in <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3041" title="feature request: Arch independent binary representations (closed: fixed)">#3041</a>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3379#changelog
http://ghc.haskell.org/trac/ghc/ticket/3511
http://ghc.haskell.org/trac/ghc/ticket/3511#3511: port GHC to OpenBSD/sparc64 (unregisterised is fine)Mon, 14 Sep 2009 03:00:44 GMTzooko<p>
Folks:
</p>
<p>
I'm a developer of the Tahoe-LAFS open source project (<a class="ext-link" href="http://allmydata.org"><span class="icon"></span>http://allmydata.org</a> ) and we use darcs, and there is a contributor who would like to help us support Tahoe-LAFS on OpenBSD/sparc64 (note: not OpenBSD/sparc). It would be really nice if that contribute could use darcs to get the latest Tahoe-LAFS source code and to contribute patches. But, GHC isn't ported to OpenBSD/sparc64. This ticket is to request the feature of a port of GHC to OpenBSD/sparc64. An unregisterised port would be fine!
</p>
<p>
Thanks!
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3511#changelog
http://ghc.haskell.org/trac/ghc/ticket/3559
http://ghc.haskell.org/trac/ghc/ticket/3559#3559: split ghci modules off into their own packageSat, 03 Oct 2009 00:46:47 GMTigloo<p>
ghci code should be split into bits that are always compiled (and always work), and modules that are in a separate <tt>ghci</tt> package. The current situation means that clients of the GHC API cannot specify whether or not they need the ghci modules (or other code inside <tt>GHCI</tt> ifdefs), and means that clients may accidentally end up using ghci-only interfaces without realising it. This is not just hypothetical: haddock has grown a dependency on ghci code: <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3558" title="task: Make haddock compilable without ghci being enabled (closed: fixed)">#3558</a>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3559#changelog
http://ghc.haskell.org/trac/ghc/ticket/3712
http://ghc.haskell.org/trac/ghc/ticket/3712#3712: Implement -dynamic-lib optionWed, 02 Dec 2009 11:20:48 GMTsimonmar<p>
The proposal is to add a new option <tt>-dynamic-lib</tt>, to be used when building a shared library. It would be both a compile-time and a link-time option, and could be used with <tt>--make</tt> to build a complete shared library in one go. It would avoid the pitfalls caused by there being combinations of <tt>-dynamic</tt> and <tt>-fPIC</tt> don't do what the user expects.
</p>
<p>
Specifically, <tt>-dynanmic-lib</tt> would imply <tt>-dyanamic</tt>, <tt>-fPIC</tt> where necessary, and <tt>-shared</tt> when linking.
</p>
<p>
See <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3705" title="bug: -fPIC without -dynamic silently ignored (closed: wontfix)">#3705</a> for more discussion.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3712#changelog
http://ghc.haskell.org/trac/ghc/ticket/3713
http://ghc.haskell.org/trac/ghc/ticket/3713#3713: Track -dynamic/-fPIC to avoid obscure linker errorsWed, 02 Dec 2009 11:25:19 GMTsimonmar<p>
Using the wrong combination of <tt>-dynamic</tt> and/or <tt>-fPIC</tt> can lead to obscure linker errors, see e.g. <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3705" title="bug: -fPIC without -dynamic silently ignored (closed: wontfix)">#3705</a>. We should track whether an object file was compiled with <tt>-dynamic</tt> and <tt>-fPIC</tt> so that we can give better error messages before running the linker.
</p>
<p>
<strong>See also</strong>
</p><div><dl class="wiki compact"><dt><a class="new" href="/trac/ghc/ticket/3712" title="Implement -dynamic-lib option">#3712</a></dt><dd>Implement -dynamic-lib option</dd></dl></div><p>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3713#changelog
http://ghc.haskell.org/trac/ghc/ticket/3755
http://ghc.haskell.org/trac/ghc/ticket/3755#3755: Improve join point inliningTue, 15 Dec 2009 10:57:00 GMTsimonpj<p>
This ticket relates to the paper "Optimising generics is easy" <a class="ext-link" href="http://www.dreixel.net/research/pdf/ogie.pdf"><span class="icon"></span>http://www.dreixel.net/research/pdf/ogie.pdf</a>. Jose writes (about a case where inlining doesn't work well):
</p>
<blockquote>
<p>
I put a minimal source code for this test and resulting Core
(with GHC 6.13.20091115) in <a class="ext-link" href="https://subversion.cs.uu.nl/repos/staff.jpm.public/Inline/"><span class="icon"></span>https://subversion.cs.uu.nl/repos/staff.jpm.public/Inline/</a>.
<tt>UpdateInt</tt> behaves great: in <tt>UpdateInt.core.O1.hs</tt>, there are no traces of
generic representations in testOne, testTwo, testThree and testFour.
</p>
</blockquote>
<blockquote>
<p>
<tt>UpdateString</tt>, however, does not behave so well. In <tt>UpdateString.core.O1.hs</tt>,
<tt>Test.testLogic_updateString</tt> still has loads of generic representations.
</p>
</blockquote>
<p>
It's easy to see what is happening. Compile <tt>UpdateString</tt> (which I've attached to this ticket) with <tt>-ddump-simpl</tt>, and look at the core. You see stuff like
</p>
<pre class="wiki">Rec { $j1_rx32 = \x. <big nested case expression>
; f = \y. ....($j1_rx32 <big constructor expression>)
---($j1_rx32 <big constructor expression)....
}
</pre><p>
So here the <tt>$j</tt> (which is a "join point") isn't inlined because it's big, although if it <em>were</em> inlined there would be much goodness because the case expressions would cancel with the explicit constructors.
</p>
<p>
Why did this happen despite lots of INLINE pragmas? I have not followed all the details, but I'm guessing that if we have, say
</p>
<pre class="wiki"> {-# INLINE from #-}
from = \x. case x of from_alts
{-# INLINE to #-}
to = \x. case x of to_alts
</pre><p>
and we try to optimize this call:
</p>
<pre class="wiki">from (mapT f (to x))
</pre><p>
then after inlining <tt>from</tt>, <tt>mapT</tt>, and <tt>to</tt> we'll get
</p>
<pre class="wiki">case (case (case x of to_alts) of map_alts) of from_alts
</pre><p>
And now the case-of-case transform happens, which creates the join points to avoid duplicating map_alts, from_alts into every branch of to_alts. You may say that we've already said that it's ok to duplicate from (and hence from_alts) but we duplicated it once when we inlined it, and then we forget the origin of the code. And indeed, in the worse case you could get a quadratic blow up; and there are only two functions involved. So I'm not unhappy with that.
</p>
<p>
However, it does make me wonder whether we could not do a better job on the above Rec {..}. Two thoughts occur.
</p>
<ol><li>We could beef up <tt>SpecConstr</tt>. It doesn't fire at the moment for some reason, even with -O2
</li></ol><ol start="2"><li>If we have
<pre class="wiki">f = \x. case x of { C1 x11..x1n -> e1; ... Ck xk1 ... xkm -> ek }
</pre>maybe we should worker-wrapper it to
<pre class="wiki">f1 x1 .. x1n = e1
...
fn xk1 .. xkm = en
f = \x of pi -> fi xi
</pre>and now inline f. The net effect is very similar to the way join points work right now, but it would make it multi-level. In fact, doing this might simplify and generalise the way that join points are currently done, where (rather arbitrarily) we duplicate the outer layer of a single case.
</li></ol><p>
Simon
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3755#changelog
http://ghc.haskell.org/trac/ghc/ticket/3946
http://ghc.haskell.org/trac/ghc/ticket/3946#3946: Better diagnostic when entering a GC'd CAFMon, 29 Mar 2010 10:07:42 GMTsimonmar<p>
Currently a GC'd CAF contains a dangling pointer, so entering it will result in a segfault or some other random failure. It would be better to give a useful diagnostic in this case (see <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3900" title="merge: CAFs used after GC with shared libs (closed: fixed)">#3900</a>), not only to detect when <tt>keepCAFs</tt> is needed, but also to help find bugs in the code generator's SRT table generation and GC bugs.
</p>
<p>
Here is one way it could be done. We use the static link field of a static closure to indicate whether the closure is live or not:
</p>
<ul><li>link field is non-zero if and only if the closure was reachable at the last GC, otherwise it is zero
</li></ul><p>
if an <tt>IND_STATIC</tt> closure has a zero link field, then we know for sure that the closure pointed to by the <tt>IND_STATIC</tt> is invalid and entering the <tt>IND_STATIC</tt> should give a helpful error message.
</p>
<p>
To implement this:
</p>
<ul><li>on entering a CAF, set the link field to 1.
</li><li>at the beginning of (major) GC, set all the link fields for static closures that were reachable during the last major GC to zero
</li><li>during GC, link fields for reachable static closures get set to non-zero as they are linked onto first the static_objects list and then the scavenged_static_objects list.
</li></ul><p>
One problem is that this scheme means traversing and writing to all the static closures at the beginning of GC, when some of them may be dead, and many will not be in the cache. The current way of doing this at the end of GC is better from a cache perspective. To refine the above approach, we could do the extra zeroing phase at the beginning of GC for <tt>IND_STATIC</tt> closures only, and the others would get the current treatment.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3946#changelog
http://ghc.haskell.org/trac/ghc/ticket/4121
http://ghc.haskell.org/trac/ghc/ticket/4121#4121: Refactor the plumbing of CafInfo to make it more robustMon, 07 Jun 2010 15:31:17 GMTdterei<p>
While comping GHC Head using the devel1 flavour and ghc-6.12.2 as the bootstrap compiler, I get the following assertion failure:
</p>
<pre class="wiki">"inplace/bin/ghc-stage1" -H64m -O -fasm -package-name base-4.3.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.2.0.0 -package integer-gmp-0.2.0.0 -package rts-1.0 -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XStandaloneDeriving -XPatternGuards -XEmptyDataDecls -XNoImplicitPrelude -XCPP -no-user-package-conf -rtsopts -O -dcore-lint -fno-warn-deprecated-flags -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/base/./Control/Applicative.hs -o libraries/base/dist-install/build/Control/Applicative.o
WARNING: file compiler/simplCore/CSE.lhs line 349 a_aup
WARNING: file compiler/simplCore/CSE.lhs line 349 a_aup
WARNING: file compiler/stgSyn/CoreToStg.lhs line 220
Control.Applicative.$fAlternativeSTM
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 6.13 for i386-unknown-linux):
ASSERT failed! file compiler/stgSyn/CoreToStg.lhs line 187
...blah...
base:Control.Applicative.$fAlternativeSTM{v rk} [gid[DFunId]] =
[] \u srt:SRT:[] []
let {
sat_s1oj{v} [lid] =
[] \r srt:SRT:[] [eta_B1{v} [lid]] retry#{v} [eta_B1{v} [lid]];
} in
base:Control.Applicative.D:Alternative{d rra} [base:Control.Applicative.$fApplicativeSTM{v r2q} [gid[DFunId]]
sat_s1oj{v} [lid]
base:GHC.Conc.orElse1{v re9} [gid]
base:Control.Applicative.$fAlternativeSTM3{v r2n} [gid]
base:Control.Applicative.$fAlternativeSTM1{v r2l} [gid]];
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre><p>
This is on the 32bit MSRC machine by the way. On my own laptop running Ubuntu 10.04 I don't get this (bootstrap compiler is 6.12.1 though).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4121#changelog
http://ghc.haskell.org/trac/ghc/ticket/4243
http://ghc.haskell.org/trac/ghc/ticket/4243#4243: Make a proper options parser for the RTSThu, 05 Aug 2010 00:27:47 GMTigloo<p>
The RTS options parsing is getting increasingly crufty, and the new <tt>rtsOptsEnabled</tt> options have made it even worse. We should really have a proper options parser.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4243#changelog
http://ghc.haskell.org/trac/ghc/ticket/4374
http://ghc.haskell.org/trac/ghc/ticket/4374#4374: Remove in-tree gmpWed, 06 Oct 2010 15:11:57 GMTigloo<p>
We already have the binary GMP DLL for Windows in the GHC tree. We should add the binary GMP dev stuff too, and then get rid of the in-tree GMP source. That would reduce build times, and simplify the build system.
</p>
<p>
I'm assuming installing GMP on other non-Windows OSes is not painful. We probably want to point to a framework for OS X users to use.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4374#changelog
http://ghc.haskell.org/trac/ghc/ticket/4941
http://ghc.haskell.org/trac/ghc/ticket/4941#4941: SpecConstr generates functions that do not use their argumentsTue, 01 Feb 2011 11:30:04 GMTsimonpj<p>
Consider this function:
</p>
<pre class="wiki">f :: Int -> (Bool,Bool) -> Bool -> Bool
f 0 x y = y
f n (p,q) y = f (n-1) (p,q) q
</pre><p>
<tt>SpecConstr</tt> does a reasonable job, but ends up with a function like this:
</p>
<pre class="wiki">T4908a.f_$s$wf =
\ (sc_sp4 :: GHC.Prim.Int#)
(sc1_sp5 :: GHC.Types.Bool)
(sc2_sp6 :: GHC.Types.Bool)
(sc3_sp7 :: GHC.Types.Bool) ->
case sc_sp4 of ds_Xom {
__DEFAULT ->
T4908a.f_$s$wf (GHC.Prim.-# ds_Xom 1) sc1_sp5 sc2_sp6 sc2_sp6;
0 -> sc3_sp7
}
</pre><p>
Note that <tt>sc1_sp5</tt> is passed around the loop but never used.
</p>
<p>
I had a quick go at trying to make <tt>SpecConstr</tt> cleverer, but absence info requires a fixpoint analysis, which the existing <tt>ArgOcc</tt> stuff doesn't do. Nor can we rely on absence analysis from earlier in the compiler, because CSE invalidates it.
</p>
<p>
A possibility would be to run strictness/absence analysis again after <tt>SpecConstr</tt>, which would pick this up. I'm not sure what other consequences this would have.
</p>
<p>
So there's an opportunity here, but I'm not sure how much it matters in practice.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4941#changelog
http://ghc.haskell.org/trac/ghc/ticket/4960
http://ghc.haskell.org/trac/ghc/ticket/4960#4960: Better inlining test in CoreUnfoldTue, 15 Feb 2011 13:15:36 GMTsimonpj<p>
Consider this
</p>
<pre class="wiki">f x = let
$j y = case x of { True -> e1; False -> e2 }
in
case x of
True -> ...$j y1...
False -> ...$j y2...
</pre><p>
If a function that scrutinises its argument is applied to a constructor, it becomes much keener to inline. But in this example the function scrutinises a <em>free variable</em> that is evaluated to a known constructor at the call site. At the moment this is ignored, and <tt>$j</tt> may well not be inlined in situations where it would be jolly good to do so.
</p>
<p>
This shows up in test <tt>perf/should_run/MethSharing</tt> where the join points created early only inline because <tt>exprIsDupable</tt> is <em>just</em> generous enough to do so. If you reduce <tt>CoreUtils.dupAppSize</tt> by 1, the join point doesn't inline any more. But it should.
</p>
<p>
The solution is fairly easy: compute discounts on free varaibles as well as arguments. I'm making a ticket because I don't want to execute on this today.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4960#changelog