Re: [GHC] #7162: RULES that never fire (automatically)
#7162: RULES that never fire (automatically) ---+ Reporter: andygill | Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.8.1 Component: Compiler |Version: 7.7 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by simonpj): Yes (1) looks best to me. Alternatively, you could make `[~]` parse as an activation but check in INLINE and SPECIALISE productions that it didn't come back as `NeverActive`. Regardless, please add comments in the parser to explain what is going on. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7162#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7476: -ddump-minimal-imports confused if first line is an import
#7476: -ddump-minimal-imports confused if first line is an import
-+--
Reporter: dag | Owner: simonpj
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version:
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by simonpj@…):
commit 156d30d76c87230d1bb5374ccec4aa73387fec9a
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Tue Dec 4 10:58:36 2012 +
Fix buglet in -ddump-minimal-imports (Trac #7476)
We were mixing up the *implicit* import of Prelude
with a user-written import declaration
compiler/rename/RnNames.lhs | 40
+++-
1 files changed, 27 insertions(+), 13 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7476#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7459: deriving Generic does not work with TypeLits
#7459: deriving Generic does not work with TypeLits
-+--
Reporter: maxtaldykin | Owner: dreixel
Type: feature request | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Other
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by simonpj@…):
commit 61f770f6df66e75c8920c17840670bea971062bf
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Sat Dec 1 18:29:21 2012 +
isTauTy should be True for LitTy (see Trac #7459)
compiler/typecheck/TcType.lhs |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7459#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7347: Existential data constructors should not be promoted
#7347: Existential data constructors should not be promoted
---+
Reporter: simonpj | Owner:
Type: bug | Status: closed
Priority: normal| Milestone:
Component: Compiler |Version: 7.6.1
Resolution: fixed | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase: polykinds/T7347 | Blockedby:
Blocking:|Related:
---+
Comment(by simonpj@…):
commit c0d846917846d303be48d9dc43fb047863ed14ea
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Wed Dec 5 11:07:38 2012 +
Allow existential data constructors to be promoted
This reverts the change in Trac #7347, which prevented promotion
of existential data constructors. Ones with constraints in
their types, or kind polymorphism, still can't be promoted.
compiler/basicTypes/DataCon.lhs |8 +---
compiler/types/TyCon.lhs|6 --
2 files changed, 9 insertions(+), 5 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7347#comment:15
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7347: Existential data constructors should not be promoted
#7347: Existential data constructors should not be promoted
---+
Reporter: simonpj | Owner:
Type: bug | Status: merge
Priority: normal| Milestone:
Component: Compiler |Version: 7.6.1
Resolution: fixed | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase: polykinds/T7347 | Blockedby:
Blocking:|Related:
---+
Changes (by simonpj):
* status: closed = merge
Comment:
After further discussion with Richard and Stephanie we decided to promote
data constructors where
* The type constructor has no kind polymorphism; indeed has kind `* -
- *`.
* The data constructor has no constraints (equality or otherwise) in its
type
* The argument types of the data constructor are all promotable
This restores the 7.6.1 behaviour, and that turns out to be useful for
Richard and/or Pedro.
I'm not sure why Stefan's original bug report is a bug. In his example
{{{
data K = forall a. T a -- promotion gives 'T :: forall k. k - K
data G :: K - * where
D :: G (T [])
}}}
the promoted kind of `'T` is poly-kinded, and that makes its use in `D`
fine. So currently it is accepted and I think we agree it should be.
The reminaing open issue concerns data types that have some promotable and
some non-promotable constructors, but I'll open a new ticket for that.
Ian, I this this should merge smoothly onto 7.6.1, along with a doc patch
that I'll commit shortly.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7347#comment:16
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7476: -ddump-minimal-imports confused if first line is an import
#7476: -ddump-minimal-imports confused if first line is an import -+-- Reporter: dag | Owner: igloo Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * owner: simonpj = igloo Comment: Fixed. Ian: I'm not sure how to set up a regression test for this, becuase it involves looking at an output file `M.imports`. Could you do that please? It would do no harm to merge this to 7.6, but it's hardly a big deal. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7476#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7481: Partially promoted data types
#7481: Partially promoted data types
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: high | Milestone: 7.8.1
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Consider
{{{
data D a where
D1 :: a - D a
D2 :: (a~Int) = D a
D3 :: forall (a:k). Proxy a - D b
}}}
Is `D` a promoted type?
Well, `D1` is promotable, but `D2` is not because of constraints in its
type, and neither is `D3` because it uses kind polymorphism. It's a bit
odd to promote only one of the three constructors, but that is what
happens right now.
We should probably check for promotability of all data constructors, and
promote all or none. A bit of fiddling around is need to do this, so I'm
opening a ticket. It's not terribly pressing.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7481
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7481: Partially promoted data types
#7481: Partially promoted data types
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: high | Milestone: 7.8.1
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Description changed by simonpj:
Old description:
Consider
{{{
data D a where
D1 :: a - D a
D2 :: (a~Int) = D a
D3 :: forall (a:k). Proxy a - D b
}}}
Is `D` a promoted type?
Well, `D1` is promotable, but `D2` is not because of constraints in its
type, and neither is `D3` because it uses kind polymorphism. It's a bit
odd to promote only one of the three constructors, but that is what
happens right now.
We should probably check for promotability of all data constructors, and
promote all or none. A bit of fiddling around is need to do this, so I'm
opening a ticket. It's not terribly pressing.
New description:
Consider
{{{
{-# LANGUAGE DataKinds, PolyKinds #-}
data D a where
D1 :: a - D a
D2 :: (a~Int) = D a
D3 :: forall (a:k). Proxy a - D b
}}}
Is `D` a promoted type?
Well, `D1` is promotable, but `D2` is not because of constraints in its
type, and neither is `D3` because it uses kind polymorphism. It's a bit
odd to promote only one of the three constructors, but that is what
happens right now.
We should probably check for promotability of all data constructors, and
promote all or none. A bit of fiddling around is need to do this, so I'm
opening a ticket. It's not terribly pressing.
--
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7481#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7473: getModificationTime gives only second-level resolution
#7473: getModificationTime gives only second-level resolution +--- Reporter: duncan | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/directory | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | +--- Changes (by igloo): * difficulty: = Unknown Comment: Related: #6160 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7473#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7481: Partially promoted data types
#7481: Partially promoted data types -+-- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by goldfire): * cc: eir@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7481#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7482: GHC.Event overwrites main IO managers hooks to RTS
#7482: GHC.Event overwrites main IO managers hooks to RTS -+-- Reporter: AndreasVoellmy| Owner: Type: bug | Status: new Priority: normal| Component: libraries/base Version: 7.4.1 | Keywords: IO Manager, RTS Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking:|Related: -+-- The IO manager registers two file descriptors with the RTS which the RTS uses to send control and wakeup signals to the IO manager. The main IO manager is started up by default and registers some file descriptors that it has allocated with the RTS. The base package also exposes a GHC.Event module which when initialized will also register files with the RTS, overwriting the main IO manager's files. Now the RTS can no longer signal the main IO manager. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7482 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2431: Allow empty case analysis (was: allow empty case analysis)
#2431: Allow empty case analysis
+---
Reporter: RalfHinze| Owner:
Type: feature request | Status: new
Priority: low | Milestone: _|_
Component: Compiler | Version: 6.8.3
Keywords: empty case analysis | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
+---
Comment(by simonpj):
I didn't find the above entirely clear, so Richard elaborates: consider:
{{{
data a :~: b where
Refl :: a :~: a
absurd :: True :~: False - a
}}}
Now, I want to write a term binding for `absurd`. Here are two candidates:
{{{
absurd x = error absurd-- (A)
absurd x = case x of {} -- (B)
}}}
I much prefer (B). Why? Because GHC can figure out that `(True :~:
False)` is an empty type. So (B) has no partiality and, (if #3927 is
fixed) I should be able to compile with `-fwarn-incomplete-patterns` and
`-Werror`.
On the other hand (A) looks dangerous, and GHC doesn't check to make sure
that, in fact, the function can never get called.
The bottom line, for me at least, is that I want to avoid the partial
constructs (incomplete patterns, undefined, etc) in Haskell as much as
possible, especially when I'm leveraging the type system to a high degree.
The lack of empty case statements forces me to use undefined where it
isn't really necessary.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2431#comment:11
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7482: GHC.Event overwrites main IO managers hooks to RTS
#7482: GHC.Event overwrites main IO managers hooks to RTS -+-- Reporter: AndreasVoellmy| Owner: Type: bug | Status: new Priority: normal| Milestone: Component: libraries/base| Version: 7.4.1 Keywords: IO Manager, RTS | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * difficulty: = Unknown Comment: Andreas: do you know how to fix this? (I don't.) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7482#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7482: GHC.Event overwrites main IO managers hooks to RTS
#7482: GHC.Event overwrites main IO managers hooks to RTS -+-- Reporter: AndreasVoellmy| Owner: Type: bug | Status: new Priority: normal| Milestone: Component: libraries/base| Version: 7.4.1 Keywords: IO Manager, RTS | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by AndreasVoellmy): Here is a possible fix: GHC.Event.new should create a new IO manager, but should not register the control file descriptors with the RTS. The result is that the main IO manager's control file descriptors are still registered with the RTS, but the RTS now has no way of sending control or wakeup messages to the user's IO manager. From what I can tell, the RTS uses the registered file descriptors in the following ways: 1. to call ensureIOManagerIsRunning, which starts the main (i.e. built-in) IO manager. 2. to call ioManagerWakeup, to wake up one arbitrary OS thread to enter the scheduler loop. 3. to call ioManagerDie 4. to pass an OS signal to the IO manager. I'm fairly certain that only the main IO manager needs to get 1,2 or 4. I'm not absolutely certain about 3. I.e. I'm not sure if it is OK that the RTS cannot tell the user's manager to return from a blocking poll call that it may be in and exit its polling loop. If that is important, then we may need to provide a method for the main IO manager to send the same message to the user's IO manager; i.e. upon initializing the user's IO manager, we add a reference to it in the main IO manager. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7482#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7482: GHC.Event overwrites main IO managers hooks to RTS
#7482: GHC.Event overwrites main IO managers hooks to RTS -+-- Reporter: AndreasVoellmy| Owner: Type: bug | Status: new Priority: normal| Milestone: Component: libraries/base| Version: 7.4.1 Keywords: IO Manager, RTS | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * cc: johan.tibell@… (added) Comment: Adding Johan in cc who knows about this stuff. I hope. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7482#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7460: Double literals generated bad core
#7460: Double literals generated bad core -+-- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonpj): Johan, can you drive this ticket to conclusion? Is the Right Thing to implement a `word2Double#` primitive? And `word2Float#` I guess. What exactly does it do? Just treat the word as a unsigned integer, thus behaving just like `int2Double#` (at least as I understand it)? If so why not do precisely that, rather than use workarounds? Presuambly the code generators would need to be educated. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7460#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7460: Double literals generated bad core
#7460: Double literals generated bad core -+-- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by tibbe): Simon, I don't think we need new primitives, as this is a regression and hence it used to work without extra primitives. I'm not quite sure why it regressed. Perhaps it's due to some refactoring that touches inling. Ian, do you have any idea why this regressed? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7460#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7460: Double literals generated bad core
#7460: Double literals generated bad core
-+--
Reporter: tibbe | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 7.4.2
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Runtime performance bug
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by igloo):
What's the regression exactly? In 7.0 I see
{{{
case GHC.Prim.=# i#_a1x8 0 of _ {
GHC.Bool.False -
case {__pkg_ccall_GC integer-gmp
integer_cmm_word2Integerzh GHC.Prim.Word#
- (#
GHC.Prim.Int#, GHC.Prim.ByteArray# #)}_a1yc
x#_a16l
of _ { (# s1_a1y9, d_a1ya #) -
case {__pkg_ccall integer-gmp integer_cbits_encodeDouble
GHC.Prim.Int#
- GHC.Prim.ByteArray#
- GHC.Prim.Int#
- GHC.Prim.State#
GHC.Prim.RealWorld
- (# GHC.Prim.State#
GHC.Prim.RealWorld,
GHC.Prim.Double#
#)}_a1yl
s1_a1y9 d_a1ya 0 GHC.Prim.realWorld#
}}}
as opposed to
{{{
case GHC.Prim.=# i#_a1F4 0 of _ {
GHC.Types.False -
case GHC.Integer.Type.doubleFromInteger
(GHC.Integer.Type.wordToInteger x#_a1iv)
}}}
in 7.4. Is that change what you are talking about, or are you looking at
something different?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7460#comment:7
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7460: Double literals generated bad core
#7460: Double literals generated bad core
-+--
Reporter: tibbe | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 7.4.2
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Runtime performance bug
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by tibbe):
This came up as we investigated the performance of the above program under
7.4. int-e reports the following run-times:
{{{
int-e: so ghc-7.0.3 has calls to integer_cmm_word2Integerzh and
integer_cbits_encodeDouble instead of doubleFromInteger (wordToInteger
...), so what is the difference?
[10:15am] int-e: tibbe: I get
http://int-e.cohomology.org/~bf3/haskell/doubles-7.0.3.core and
http://int-e.cohomology.org/~bf3/haskell/doubles-7.4.1.core both with -O2
-ddump-simpl
[10:17am] tibbe: int-e: I wonder what cmm integer_cbits_encodeDouble
generates
[10:17am] tibbe: int-e: whatever it does it makes a big difference to
performance
[10:27am] int-e: hmm, how big? I have 0.28s from 7.0.3, 0.27 from 7.2.1
and 0.34s from 7.4.1. 0.3 from 7.6.1. Similar for -O1.
[10:28am] int-e: (x86_64)
[10:31am] int-e: x86 is more pronounced. 0m1.903s / 0m1.794s / 0m2.511s /
0m2.046s for 7.0.3, 7.2.1, 7.4.1, 7.6.1
[10:31am] int-e: (-O1)
[10:31am] tibbe: int-e: so 20% on x86-64
[10:31am] int-e: (and atom)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7460#comment:8
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7460: Double literals generated bad core
#7460: Double literals generated bad core
-+--
Reporter: tibbe | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 7.4.2
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Runtime performance bug
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by int-e):
Looking at the CMM code, the most noticable difference seems that
ghc-7.0.3 used to generate a foreign call for the second part of the
conversion,
{{{
integer_cbits_encodeDouble((_c2ut::I64, `signed'),
(_c2uv::I64, PtrHint), (0,
`signed'))[_unsafe_call_];
}}}
while the current code (since ghc-7.2.1) sets up a stack frame and jumps
into the integer package.
Not sure how much of the observed differences that explains.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7460#comment:9
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #6040: Adding a type signature changes heap allocation into stack allocation without changing the actual type
#6040: Adding a type signature changes heap allocation into stack allocation without changing the actual type -+-- Reporter: tibbe | Owner: simonpj Type: bug | 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:| -+-- Changes (by tibbe): * cc: fox@… (added) Comment: I can't reproduce this with a smaller example so I'm deferring this to Milan Straka, who first discovered the issue. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6040#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7460: Double literals generated bad core
#7460: Double literals generated bad core -+-- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by tibbe): Even if 7.0 was a bit better it seems like having a `word2Double#` and a `word2Float#` primop makes sense. They should behave in the same way as `fromIntegral (w :: Word) :: Double` and `fromIntegral (w :: Word) :: Float` does today presumably. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7460#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7460: Double literals generated bad core
#7460: Double literals generated bad core -+-- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by tibbe): This is how the C standard defines integer to/from floating point conversions: 6.3.1.4 Real floating and integer 1 When a finite value of real floating type is converted to an integer type other than _Bool, the fractional part is discarded (i.e., the value is truncated toward zero). If the value of the integral part cannot be represented by the integer type, the behavior is undefined. 61) 2 When a value of integer type is converted to a real floating type, if the value being converted can be represented exactly in the new type, it is unchanged. If the value being converted is in the range of values that can be represented but cannot be represented exactly, the result is either the nearest higher or nearest lower representable value, chosen in an implementation-defined manner. If the value being converted is outside the range of values that can be represented, the behavior is undefined. Results of some implicit conversions may be represented in greater range and precision than that required by the new type (see 6.3.1.8 and 6.8.6.4). 61) The remaindering operation performed when a value of integer type is converted to unsigned type need not be performed when a value of real floating type is converted to unsigned type. Thus, the range of portable real floating values is (−1, Utype_MAX+1). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7460#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7460: Double literals generated bad core
#7460: Double literals generated bad core -+-- Reporter: tibbe | Owner: tibbe Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by tibbe): * owner: = tibbe Comment: I will try to add the needed primops. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7460#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #6040: Adding a type signature changes heap allocation into stack allocation without changing the actual type
#6040: Adding a type signature changes heap allocation into stack allocation
without changing the actual type
-+--
Reporter: tibbe | Owner: simonpj
Type: bug | 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:|
-+--
Comment(by milan):
I was asked by Johan to demonstrate the issue.
I would like to note that I am not sure it is even a bug -- I understand
what is going on and I am not sure what a better behaviour would be -- but
maybe the transformation Simon suggests is a good idea.
Consider two methods `delete1` and `delete2` which delete all occurences
of a given key in the list:
{{{
module Test ( delete1, delete2 ) where
delete1 :: Eq k = k - [k] - [k]
delete1 = go
where go _ [] = []
go k (x:xs) | k == x = go k xs
| otherwise = x : go k xs
delete2 :: Eq k = k - [k] - [k]
delete2 = go
where go :: Eq k = k - [k] - [k]
go _ [] = []
go k (x:xs) | k == x = go k xs
| otherwise = x : go k xs
}}}
The difference is that in the first case, `go` is a closure which captures
the `Eq` dictionary of the outer function. In the second case, `go` is
being given the `Eq` dictionary as a parameter and therefore floats out of
`delete2`. STG illustrates this nicely:
{{{
STG syntax:
Test.delete1 =
\r [$dEq_sql eta_sqs eta1_sqt]
let {
go_sqq =
sat-only \r [ds_sqm ds1_sqh]
case ds1_sqh of wild_sqO {
[] - [] [];
: x_sqn xs_sqp -
case GHC.Classes.== $dEq_sql ds_sqm x_sqn of
wild1_sqP {
GHC.Types.False -
let { sat_sqN = \u [] go_sqq ds_sqm xs_sqp;
} in : [x_sqn sat_sqN];
GHC.Types.True - go_sqq ds_sqm xs_sqp;
};
};
} in go_sqq eta_sqs eta1_sqt;
SRT(Test.delete1): []
Test.delete2_go =
\r [$dEq_sqB ds_sqC ds1_sqx]
case ds1_sqx of wild_sqQ {
[] - [] [];
: x_sqD xs_sqF -
case GHC.Classes.== $dEq_sqB ds_sqC x_sqD of wild1_sqS {
GHC.Types.False -
let { sat_sqR = \u [] Test.delete2_go $dEq_sqB ds_sqC
xs_sqF;
} in : [x_sqD sat_sqR];
GHC.Types.True - Test.delete2_go $dEq_sqB ds_sqC xs_sqF;
};
};
SRT(Test.delete2_go): []
Test.delete2 =
\r [$dEq_sqK eta_sqL eta1_sqM]
Test.delete2_go $dEq_sqK eta_sqL eta1_sqM;
SRT(Test.delete2): []
}}}
The result is that `delete1` has to heap-allocate the dictionary while
`delete2` does not.
{{{
Test_delete1_info()
{ update_frame: none
label: Test_delete1_info
rep:HeapRep static { Fun {arity: 3 fun_type: ArgSpec 20} }
}
crz:
Hp = Hp + 8;
if (Hp HpLim) goto crC;
I32[Hp - 4] = sqq_info;
I32[Hp + 0] = I32[Sp + 0];
R1 = Hp - 2;
Sp = Sp + 4;
jump sqq_info ();
...
}}}
The performance difference is very minor -- `delete1` needs one more two-
word heap allocation. The time difference will not probably be measurable.
I notised this only because I monitor heap allocations in `containers`
code as they cause ghc perf tests which monitor heap allocation to fail.
BTW, we use identical `insert` and `go` functions in containers because
the outer is marked `INLINE` in pre-7.0 GHC.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6040#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7466: [PATCH] integer-gmp silently ignores --with-gmp-* whenever it finds GMP.framework in the system-standard path (was: [PATCH] Prefer libgmp/libgmp3 over GMP.framework on Darwin)
#7466: [PATCH] integer-gmp silently ignores --with-gmp-* whenever it finds GMP.framework in the system-standard path --+- Reporter: PHO| Owner: Type: bug| Status: patch Priority: normal | Milestone: Component: libraries (other) | Version: 7.6.1 Keywords: | Os: MacOS X Architecture: Unknown/Multiple | Failure: Other Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by PHO): * status: infoneeded = patch Comment: Sorry, my explanation was a bit misleading. Replying to [comment:2 igloo]: Why is the non-framework preferable? Most package managers, including my favorite [http://www.pkgsrc.org/ pkgsrc], install `libgmp` to some non-standard locations. If the `configure` script ignores whatever paths specified with `--with-gmp- includes`/`--with-gmp-libraries`, the resulting binary might end up being linked to `GMP.framework` in the system-standard path (which might be installed by some 3rd party softwares), instead of `libgmp` installed with a package manager. For that reason [http://pkgsrc.se/wip/ghc pkgsrc- wip/ghc] has locally had the above patch for a long time but I think it's worth merging to the upstream. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7466#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4268: Annotation extension needs a flag
#4268: Annotation extension needs a flag ---+ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal| Milestone: 7.6.2 Component: Compiler |Version: 7.0.4 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Difficulty: Easy (less than 1 hour) Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by juhpetersen): * cc: juhp@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4268#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
