#7587: Kind variables are not renamed
-----------------------------+----------------------------------------------
Reporter: monoidal | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking: | Related:
-----------------------------+----------------------------------------------
{{{
ghci -XPolyKinds
Prelude> data A x y
Prelude> :k A
A :: k -> k -> *
}}}
should be {{{k -> l -> *}}}. The 'k's are allowed to be different, there
is just a name collision.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7587>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7519: CLK_TCK is not always a constant
---------------------------------+------------------------------------------
Reporter: singpolyma | Owner:
Type: bug | Status: merge
Priority: normal | Milestone: 7.8.1
Component: libraries/base | Version: 7.7
Keywords: qnx | Os: Other
Architecture: Unknown/Multiple | Failure: Building GHC failed
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Changes (by simonmar):
* milestone: => 7.8.1
Comment:
The ticket state "merge" means you want the change in the stable branch
(7.6). Will it help to merge it into the 7.6 branch?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7519#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#6135: Unboxed Booleans
---------------------------------+------------------------------------------
Reporter: benl | Owner: jstolarek
Type: feature request | Status: new
Priority: normal | Milestone: 7.8.1
Component: Compiler | Version: 7.4.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: #605 |
---------------------------------+------------------------------------------
Comment(by simonmar):
I agree with Simon, I think we already got a lot of the benefit to be had
here from pointer tagging. Perhaps for enums larger than the threshold (3
or 7 for 32-bit or 64-bit respectively) we should be unboxing them in
worker/wrapper. It wouldn't be hard to write some examples by hand and
measure the difference between using enums and `Int#`.
I would like to see the simplification I mentioned above - changing the
comparison primops to return `Int#` rather than `Bool` - and I believe
that would lead to more optimisations later. At the least it would expose
the magic `tagToEnum#` that arises from these primops to the simplifier,
where it could be optimised away.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:15>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#6135: Unboxed Booleans
---------------------------------+------------------------------------------
Reporter: benl | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 7.8.1
Component: Compiler | Version: 7.4.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: #605 |
---------------------------------+------------------------------------------
Comment(by simonpj):
See [wiki:PrimBool].
Janek, great initiative thanks. But I think it would be helpful to
articulate a very clear story about the ''goal''. I believe that the goal
is to achieve much better performance, without changing the source
language. The programmer does not change the program, but they run
faster.
If so, then can we have (on the wiki page, not here):
* A description of ''why'' programs will go faster, with specific
examples.
* Some example programs that will in fact go faster. Maybe you can code
the examples up in Haskell, using inconvenient and messy `Int#` or
whatever, to demonstrate that they really do go faster.
The sub-text is that I only want to introduce new complexity if it
demonstrably buys us something.
One reason that things may go faster is this. At the moment, if a
function is strict in a `Bool` argument, that argument is still passed
boxed. But it could very sensibly be passed unboxed instead, just as we
do with pairs, say. So perhaps strictness analysis would work well with
unboxed enumerations.
But it's not entirely obvious that it will. Unboxing a pair is great
because the pair is never allocated. But enumerations are never allocated
either! (`True` and `False` are statically allocated.) Moreover, even
though passing `True` passes a pointer to a (statically allocated) heap
object, the True/False tag is in the ''pointer'' (see
[http://research.microsoft.com/en-us/um/people/simonpj/papers/ptr-
tag/index.htm Faster laziness using dynamic pointer tagging]), so no
memory access is needed when discriminating True/False. So the gains from
unboxing may be modest.
Pointer tagging only works for data types with a handful of constructors.
Big enumerations really do keep the tag in memory. (See the paper.)
None of this is to say it's a bad idea. Just that we need clarity about
where the gains are going to come from, and measurements that suggest the
gains are real.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#5801: Document GHC Optimisation Passes
---------------------------------+------------------------------------------
Reporter: dterei | Owner: dterei
Type: task | Status: new
Priority: normal | Milestone: 7.6.2
Component: Documentation | Version:
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Documentation bug
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Changes (by dterei):
* cc: benl (added)
Comment:
Manuel or Ben are you able to document the DPH flags? Just -vectorise and
-void-vect are remaining and then we can close this.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5801#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#709: "Fixup too large" error with -fasm on PowerPC
----------------------------------+-----------------------------------------
Reporter: simonmar | Owner:
Type: bug | Status: patch
Priority: low | Milestone: 6.8.1
Component: Compiler (NCG) | Version: 7.7
Resolution: | Keywords:
Os: Unknown/Multiple | Architecture: powerpc
Failure: Building GHC failed | Difficulty: Moderate (less than a day)
Testcase: | Blockedby:
Blocking: | Related:
----------------------------------+-----------------------------------------
Comment(by simonmar):
Ok, I redid your first patch (see above), your other changes are fine
except don't forget to take into account the effect of alignment, which
could add a further `(word_size - 1)` bytes to the size of the info table.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/709#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
