#5925: Add inline version of newArray#
---------------------------------+------------------------------------------
Reporter: tibbe | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 7.6.2
Component: Compiler | Version: 7.4.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: 4258 | Blocking:
Related: |
---------------------------------+------------------------------------------
Comment(by simonpj):
It makes a difference whether the size is known at compile time or not.
The code that emits the heap check is `entryHeapCheck` in `StgCmmHeap`.
Maybe we should talk on Skype.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5925#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4230: Template Haskell: less type checking in quotations?
---------------------------------+------------------------------------------
Reporter: simonpj | Owner:
Type: feature request | Status: new
Priority: low | Milestone: 7.6.2
Component: Compiler | Version: 7.6.3
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: | Blocking: 4124, 4125, 4128, 4135, 4170
Related: |
---------------------------------+------------------------------------------
Changes (by simonpj):
* cc: gmainlan@… (added)
* difficulty: => Unknown
Comment:
This ticket is more or less subsumed by
[http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal my
TH blog post proposal].
Geoff Mainland is working on implementing it right now.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4230#comment:17>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4230: Template Haskell: less type checking in quotations?
---------------------------------+------------------------------------------
Reporter: simonpj | Owner:
Type: feature request | Status: new
Priority: low | Milestone: 7.6.2
Component: Compiler | Version: 7.6.3
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: | Testcase:
Blockedby: | Blocking: 4124, 4125, 4128, 4135, 4170
Related: |
---------------------------------+------------------------------------------
Changes (by carter):
* version: 6.12.3 => 7.6.3
Comment:
One use case / example /motivation I encountered this week is the
following:
To make the LLVM-Base library work with cabal versions 1.16 and cabal
head, I wanted to write the following code
{{{
--- what i'd like to write, but can't because template haskell rejecting
the branch that has the wrong api version
extractCLBI x=
$(if cabalVersion >= Version [1,17,0] []
then [| getComponentLocalBuildInfo 'x CLibName |]
else [| let LocalBuildInfo { libraryConfig = Just clbi }
= 'x in clbi |]
)
}}}
{{{
--- horrible hack to support cabal versions both above and below 1.17
extractCLBI x=
$(if cabalVersion >= Version [1,17,0] []
then appE (appE ( varE $ mkName "getComponentLocalBuildInfo") (
varE 'x) ) (conE ( mkName "CLibName"))
else letE
[valD (recP
(mkName "LocalBuildInfo" )
[fieldPat (mkName "libraryConfig")
(conP (mkName "Just") [varP $ mkName
"clbi"] ) ] )
(normalB $ varE 'x) [] ]
(varE $ mkName "clbi") )
}}}
In this case, I need to explicitly write out the AST so that template
haskell doesn't barf.
Would one near term solution be to
1. do the harmonization between haskell-src-exts and TH (as suggested /
discussed elsewhere)
2. provide untypedExp, Dec, etc quasiquoters ?
this would be a pretty happy balance of allowing both the stronger and
weaker typings, and might be a reasonable first step towards actually
working on MetaHaskell
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4230#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#5925: Add inline version of newArray#
---------------------------------+------------------------------------------
Reporter: tibbe | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 7.6.2
Component: Compiler | Version: 7.4.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: 4258 | Blocking:
Related: |
---------------------------------+------------------------------------------
Comment(by tibbe):
I'm interested in getting something working first (i.e. a version of
`newArray#` that allocates inline). We can then see what we can do about
merging heap checks. Which code tackles merging these checks? The
optimization seems similar to floating plus constant folding/conditional
merging to me.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5925#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4385: Type-level natural numbers
----------------------------------------+-----------------------------------
Reporter: diatchki | Owner: diatchki
Type: feature request | Status: new
Priority: normal | Milestone: 7.6.2
Component: Compiler (Type checker) | Version:
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: | Testcase:
Blockedby: | Blocking:
Related: |
----------------------------------------+-----------------------------------
Comment(by diatchki):
Thanks, I'll take a look and try to improve the solver. Unfortunately, I
don't think that there's an easy way to work around this in the
polymorphic case. If you could instantiate the `n`s somehow, it'd get
solved, but I know that's not always an option.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4385#comment:59>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4385: Type-level natural numbers
----------------------------------------+-----------------------------------
Reporter: diatchki | Owner: diatchki
Type: feature request | Status: new
Priority: normal | Milestone: 7.6.2
Component: Compiler (Type checker) | Version:
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: | Testcase:
Blockedby: | Blocking:
Related: |
----------------------------------------+-----------------------------------
Comment(by maltem):
I'm trying out the type-nats branch and the wiki says to complain when the
solver cannot solve something, so here we go:
{{{
Bug.hs:22:29:
Could not deduce ((2 * n) ~ ((2 * n1) + 2))
from the context (n ~ (n1 + 1))
}}}
The code is attached. I'd welcome a hint how I can work around the error
(the wiki mentions that this should typically be possible, but I don't
understand how).
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4385#comment:58>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7896: Type constructor is accepted as context
----------------------------------------+-----------------------------------
Reporter: stefan | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler (Type checker)
Version: 7.6.3 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: GHC accepts invalid program | Blockedby:
Blocking: | Related:
----------------------------------------+-----------------------------------
Consider the following program:
{{{
f :: Int => () -> ()
f _ = id
}}}
It is accepted by the compiler, even though we are using a type
constructor rather than a class assertion in a type context.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7896>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#5925: Add inline version of newArray#
---------------------------------+------------------------------------------
Reporter: tibbe | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 7.6.2
Component: Compiler | Version: 7.4.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: 4258 | Blocking:
Related: |
---------------------------------+------------------------------------------
Comment(by simonpj):
If the array size is fixed at compile time, it should be easy... the heap
check can be aggregated with all the others at the start of the basic
block.
If the array size is not known at compile time, but somehow known to be
small, then with the new codegen it should be possible to just emit an
inline heap check. EXCEPT that doing so could mess up downstream fixed-
size checks. Eg
{{{
let x = f v in
let y = newArray# n# in
let z = f w in
...
}}}
Absent the `newArray#` we'd have a single heap check that made sure there
was enough space for both `x` and `z`. But we can't do that if the
`newArray#` in the middle allocates an unknown amount of space. I suppose
we could emit three heap checks... that would work I think.
A related ticket is #2387 and #2289, where we'd like to put a heap check
at the beginning of a primop case alternative, something that should now
work just fine.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5925#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
