Re: Validating with Haddock
Hi all, I have now merged in the new parser and new features onto a single branch. I'm having some issues validating with HEAD at the moment (#8661, unrelated problem) but while I get that sorted out, someone might want to try validating with Haddock changes on their own platform. The full branch is at [1]. I have squashed the changes to what I feel is the minimum number of commits until they completely stop making sense. It should apply cleanly on top of current Haddock master branch. The documentation is updated so you can read about what changed. Feel free to ask any questions. I will post again once I can confirm that the branch validates for me without any new test failures. Thanks for your patience. [1]: https://github.com/Fuuzetsu/haddock/tree/new-features -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Changing GHC Error Message Wrapping
Crumbs. You are absolutely right. I'll fix that. (It's a relic from when the
flags weren't available to the show functions.)
Simon
From: Andrew Gibiansky [mailto:andrew.gibian...@gmail.com]
Sent: 08 January 2014 17:23
To: Simon Peyton Jones
Cc: Erik de Castro Lopo; ghc-devs@haskell.org
Subject: Re: Changing GHC Error Message Wrapping
Of course :) It made sense once I realized that the `show` was generating the
string, and that it was not generated when the datatype was being constructed.
However, I don't think the `showSDocForUser` call works (I tested). It uses
`runSDoc` to generate a `Doc`. It then uses `show` on that Doc:
instance Show Doc where
showsPrec _ doc cont = showDoc doc cont
Looking at `showDoc` we see:
showDoc :: Doc - String - String
showDoc doc rest = showDocWithAppend PageMode doc rest
showDocWithAppend :: Mode - Doc - String - String
showDocWithAppend mode doc rest = fullRender mode 100 1.5 string_txt rest doc
It ultimately calls `showDocWithAppend`, which calls `fullRender` with a
hard-coded 100-column limit.
-- Andrew
On Wed, Jan 8, 2014 at 12:11 PM, Simon Peyton Jones
simo...@microsoft.commailto:simo...@microsoft.com wrote:
Well, the Show instance for a type (any type) cannot possibly respect pprCols.
It can't: show :: a - String! No command-line inputs.
I suggest something more like
doc sdoc = do { dflags - getDynFlags; unqual - getPrintUnqual; return
(showSDocForUser dflags unqual doc }
Simon
From: Andrew Gibiansky
[mailto:andrew.gibian...@gmail.commailto:andrew.gibian...@gmail.com]
Sent: 08 January 2014 00:09
To: Simon Peyton Jones
Cc: Erik de Castro Lopo; ghc-devs@haskell.orgmailto:ghc-devs@haskell.org
Subject: Re: Changing GHC Error Message Wrapping
Hello all,
I figured out that this isn't quite a bug and figured out how to do what I
wanted. It turns out that the `Show` instance for SourceError does not respect
`pprCols` - I don't know if that's a reasonable expectation (although it's what
I expected). I ended up using the following code to print these messages:
flip gcatch handler $ do
runStmt let f (x, y, z, w, e, r, d , ax, b ,c,ex ,g ,h) = (x :: Int) + y +
z RunToCompletion
runStmt f (1, 2, 3) RunToCompletion
return ()
where
handler :: SourceError - Ghc ()
handler srcerr = do
let msgs = bagToList $ srcErrorMessages srcerr
forM_ msgs $ \msg - do
s - doc $ errMsgShortDoc msg
liftIO $ putStrLn s
doc :: GhcMonad m = SDoc - m String
doc sdoc = do
flags - getSessionDynFlags
let cols = pprCols flags
d = runSDoc sdoc (initSDocContext flags defaultUserStyle)
return $ Pretty.fullRender Pretty.PageMode cols 1.5 string_txt d
where
string_txt :: Pretty.TextDetails - String - String
string_txt (Pretty.Chr c) s = c:s
string_txt (Pretty.Str s1) s2 = s1 ++ s2
string_txt (Pretty.PStr s1) s2 = unpackFS s1 ++ s2
string_txt (Pretty.LStr s1 _) s2 = unpackLitString s1 ++ s2
As far as I can tell, there is no simpler way, every function in `Pretty`
except for `fullRender` just assumes a default of 100-char lines.
-- Andrew
On Tue, Jan 7, 2014 at 11:29 AM, Andrew Gibiansky
andrew.gibian...@gmail.commailto:andrew.gibian...@gmail.com wrote:
Simon,
That's exactly what I'm looking for! But it seems that doing it dynamically in
the GHC API doesn't work (as in my first email where I tried to adjust pprCols
via setSessionDynFlags).
I'm going to look into the source as what ppr-cols=N actually sets and probably
file a bug - because this seems like buggy behaviour...
Andrew
On Tue, Jan 7, 2014 at 4:14 AM, Simon Peyton Jones
simo...@microsoft.commailto:simo...@microsoft.com wrote:
-dppr-cols=N changes the width of the output page; you could try a large number
there. There isn't a setting meaning infinity, sadly.
Simon
From: Andrew Gibiansky
[mailto:andrew.gibian...@gmail.commailto:andrew.gibian...@gmail.com]
Sent: 07 January 2014 03:04
To: Simon Peyton Jones
Cc: Erik de Castro Lopo; ghc-devs@haskell.orgmailto:ghc-devs@haskell.org
Subject: Re: Changing GHC Error Message Wrapping
Thanks Simon.
In general I think multiline tuples should have many elements per line, but
honestly the tuple case was a very specific example. If possible, I'd like to
change the *overall* wrapping for *all* error messages - how does `sep` know
when to break lines? there's clearly a numeric value for the number of columns
somewhere, but where is it, and is it user-adjustable?
For now I am just hacking around this by special-casing some error messages and
un-doing the line wrapping by parsing the messages and joining lines back
together.
Thanks,
Andrew
On Mon, Jan 6, 2014 at 7:44 AM, Simon Peyton-Jones
simo...@microsoft.commailto:simo...@microsoft.com wrote:
I think it's line 705 in types/TypeRep.lhs
pprTcApp p pp tc tys
| isTupleTyCon tc tyConArity tc == length tys
= pprPromotionQuote tc
tupleParens (tupleTyConSort tc) (sep (punctuate comma (map (pp TopPrec)
tys)))
Re: Changing GHC Error Message Wrapping
Thanks!
On Fri, Jan 10, 2014 at 9:21 AM, Simon Peyton Jones
simo...@microsoft.comwrote:
Crumbs. You are absolutely right. I’ll fix that. (It’s a relic from
when the flags weren’t available to the show functions.)
Simon
*From:* Andrew Gibiansky [mailto:andrew.gibian...@gmail.com]
*Sent:* 08 January 2014 17:23
*To:* Simon Peyton Jones
*Cc:* Erik de Castro Lopo; ghc-devs@haskell.org
*Subject:* Re: Changing GHC Error Message Wrapping
Of course :) It made sense once I realized that the `show` was generating
the string, and that it was not generated when the datatype was being
constructed.
However, I don't think the `showSDocForUser` call works (I tested). It
uses `runSDoc` to generate a `Doc`. It then uses `show` on that Doc:
instance Show Doc where
showsPrec _ doc cont = showDoc doc cont
Looking at `showDoc` we see:
showDoc :: Doc - String - String
showDoc doc rest = showDocWithAppend PageMode doc rest
showDocWithAppend :: Mode - Doc - String - String
showDocWithAppend mode doc rest = fullRender mode 100 1.5 string_txt rest
doc
It ultimately calls `showDocWithAppend`, which calls `fullRender` with a
hard-coded 100-column limit.
-- Andrew
On Wed, Jan 8, 2014 at 12:11 PM, Simon Peyton Jones simo...@microsoft.com
wrote:
Well, the Show instance for a type (any type) cannot possibly respect
pprCols. It can’t: show :: a - String! No command-line inputs.
I suggest something more like
doc sdoc = do { dflags - getDynFlags; unqual - getPrintUnqual; return
(showSDocForUser dflags unqual doc }
Simon
*From:* Andrew Gibiansky [mailto:andrew.gibian...@gmail.com]
*Sent:* 08 January 2014 00:09
*To:* Simon Peyton Jones
*Cc:* Erik de Castro Lopo; ghc-devs@haskell.org
*Subject:* Re: Changing GHC Error Message Wrapping
Hello all,
I figured out that this isn't quite a bug and figured out how to do what I
wanted. It turns out that the `Show` instance for SourceError does not
respect `pprCols` - I don't know if that's a reasonable expectation
(although it's what I expected). I ended up using the following code to
print these messages:
flip gcatch handler $ do
runStmt let f (x, y, z, w, e, r, d , ax, b ,c,ex ,g ,h) = (x :: Int)
+ y + z RunToCompletion
runStmt f (1, 2, 3) RunToCompletion
return ()
where
handler :: SourceError - Ghc ()
handler srcerr = do
let msgs = bagToList $ srcErrorMessages srcerr
forM_ msgs $ \msg - do
s - doc $ errMsgShortDoc msg
liftIO $ putStrLn s
doc :: GhcMonad m = SDoc - m String
doc sdoc = do
flags - getSessionDynFlags
let cols = pprCols flags
d = runSDoc sdoc (initSDocContext flags defaultUserStyle)
return $ Pretty.fullRender Pretty.PageMode cols 1.5 string_txt d
where
string_txt :: Pretty.TextDetails - String - String
string_txt (Pretty.Chr c) s = c:s
string_txt (Pretty.Str s1) s2 = s1 ++ s2
string_txt (Pretty.PStr s1) s2 = unpackFS s1 ++ s2
string_txt (Pretty.LStr s1 _) s2 = unpackLitString s1 ++ s2
As far as I can tell, there is no simpler way, every function in `Pretty`
except for `fullRender` just assumes a default of 100-char lines.
-- Andrew
On Tue, Jan 7, 2014 at 11:29 AM, Andrew Gibiansky
andrew.gibian...@gmail.com wrote:
Simon,
That's exactly what I'm looking for! But it seems that doing it
dynamically in the GHC API doesn't work (as in my first email where I tried
to adjust pprCols via setSessionDynFlags).
I'm going to look into the source as what ppr-cols=N actually sets and
probably file a bug - because this seems like buggy behaviour...
Andrew
On Tue, Jan 7, 2014 at 4:14 AM, Simon Peyton Jones simo...@microsoft.com
wrote:
-dppr-cols=N changes the width of the output page; you could try a large
number there. There isn’t a setting meaning “infinity”, sadly.
Simon
*From:* Andrew Gibiansky [mailto:andrew.gibian...@gmail.com]
*Sent:* 07 January 2014 03:04
*To:* Simon Peyton Jones
*Cc:* Erik de Castro Lopo; ghc-devs@haskell.org
*Subject:* Re: Changing GHC Error Message Wrapping
Thanks Simon.
In general I think multiline tuples should have many elements per line,
but honestly the tuple case was a very specific example. If possible, I'd
like to change the *overall* wrapping for *all* error messages - how does
`sep` know when to break lines? there's clearly a numeric value for the
number of columns somewhere, but where is it, and is it user-adjustable?
For now I am just hacking around this by special-casing some error
messages and un-doing the line wrapping by parsing the messages and
joining lines back together.
Thanks,
Andrew
On Mon, Jan 6, 2014 at 7:44 AM, Simon Peyton-Jones simo...@microsoft.com
wrote:
I think it’s line 705 in types/TypeRep.lhs
pprTcApp p pp tc tys
| isTupleTyCon tc tyConArity tc == length tys
= pprPromotionQuote tc
RE: High-level Cmm code and stack allocation
That documentation would be good, yes! I don't know what it means to say we
don't really have a general concept of areas any more. We did before, and I
didn't know that it had gone away. Urk! We can have lots of live areas,
notably the old area (for the current call/return parameters, the call area for
a call we are preparing, and the one-slot areas for variables we are saving on
the stack.
Here's he current story
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/StackAreas
I agree that we have no concrete syntax for talking about areas, but that is
something we could fix. But I'm worried that they may not mean what they used
to mean.
Simon
| -Original Message-
| From: Simon Marlow [mailto:marlo...@gmail.com]
| Sent: 09 January 2014 08:39
| To: Simon Peyton Jones; Herbert Valerio Riedel
| Cc: ghc-devs@haskell.org
| Subject: Re: High-level Cmm code and stack allocation
|
| On 08/01/2014 10:07, Simon Peyton Jones wrote:
| | Can't we just allocate a Cmm area? The address of an area is a
| | perfectly well-defined Cmm value.
|
| What about this idea?
|
| We don't really have a general concept of areas (any more), and areas
| aren't exposed in the concrete Cmm syntax at all. The current semantics
| is that areas may overlap with each other, so there should only be one
| active area at any point. I found that this was important to ensure
| that we could generate good code from the stack layout algorithm,
| otherwise it had to make pessimistic assumptions and use too much stack.
|
| You're going to ask me where this is documented, and I think I have to
| admit to slacking off, sorry :-) We did discuss it at the time, and I
| made copious notes, but I didn't transfer those to the code. I'll add a
| Note.
|
| Cheers,
| Simon
|
|
| Simon
|
| | -Original Message-
| | From: Simon Marlow [mailto:marlo...@gmail.com]
| | Sent: 08 January 2014 09:26
| | To: Simon Peyton Jones; Herbert Valerio Riedel
| | Cc: ghc-devs@haskell.org
| | Subject: Re: High-level Cmm code and stack allocation
| |
| | On 07/01/14 22:53, Simon Peyton Jones wrote:
| | | Yes, this is technically wrong but luckily works. I'd very much
| | | like to have a better solution, preferably one that doesn't add
| | | any extra overhead.
| |
| | | __decodeFloat_Int is a C function, so it will not touch the
| | | Haskell stack.
| |
| | This all seems terribly fragile to me. At least it ought to be
| | surrounded with massive comments pointing out how terribly fragile
| | it is, breaking all the rules that we carefully document elsewhere.
| |
| | Can't we just allocate a Cmm area? The address of an area is a
| | perfectly well-defined Cmm value.
| |
| | It is fragile, yes. We can't use static memory because it needs to
| | be thread-local. This particular hack has gone through several
| | iterations over the years: first we had static memory, which broke
| | when we did the parallel runtime, then we had special storage in the
| | Capability, which we gave up when GMP was split out into a separate
| | library, because it didn't seem right to have magic fields in the
| | Capability for one library.
| |
| | I'm looking into whether we can do temporary allocation on the heap
| | for this instead.
| |
| | Cheers,
| | Simon
| |
| |
| | Simon
| |
| | | -Original Message-
| | | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf
| | | Of Simon Marlow
| | | Sent: 07 January 2014 16:05
| | | To: Herbert Valerio Riedel; ghc-devs@haskell.org
| | | Subject: Re: High-level Cmm code and stack allocation
| | |
| | | On 04/01/2014 23:26, Herbert Valerio Riedel wrote:
| | | Hello,
| | |
| | | According to Note [Syntax of .cmm files],
| | |
| | | | There are two ways to write .cmm code:
| | | |
| | | | (1) High-level Cmm code delegates the stack handling to
| | | | GHC,
| | and
| | | | never explicitly mentions Sp or registers.
| | | |
| | | | (2) Low-level Cmm manages the stack itself, and must know
| about
| | | | calling conventions.
| | | |
| | | | Whether you want high-level or low-level Cmm is indicated by
| | | | the presence of an argument list on a procedure.
| | |
| | | However, while working on integer-gmp I've been noticing in
| | | integer-gmp/cbits/gmp-wrappers.cmm that even though all Cmm
| | | procedures
| | | have been converted to high-level Cmm, they still reference
| | | the
| | 'Sp'
| | | register, e.g.
| | |
| | |
| | | #define GMP_TAKE1_RET1(name,mp_fun) \
| | | name (W_ ws1, P_ d1) \
| | | { \
| | | W_ mp_tmp1; \
| | | W_ mp_result1; \
| | | \
| | | again:\
| | |
Re: High-level Cmm code and stack allocation
There are no one-slot areas any more, I ditched those when I rewrote the stack allocator. There is only ever one live area: either the old area or the young area for a call we are about to make or have just made. (see the data type: I removed the one-slot areas) I struggled for a long time with this. The problem is that with the semantics of non-overlapping areas, code motion optimisations would tend to increase the stack requirements of the function by overlapping the live ranges of the areas. I concluded that actually what we wanted was areas that really do overlap, and optimisations that respect that, so that we get more efficient stack usage. Cheers, Simon On 10/01/2014 15:22, Simon Peyton Jones wrote: That documentation would be good, yes! I don't know what it means to say we don't really have a general concept of areas any more. We did before, and I didn't know that it had gone away. Urk! We can have lots of live areas, notably the old area (for the current call/return parameters, the call area for a call we are preparing, and the one-slot areas for variables we are saving on the stack. Here's he current story https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/StackAreas I agree that we have no concrete syntax for talking about areas, but that is something we could fix. But I'm worried that they may not mean what they used to mean. Simon | -Original Message- | From: Simon Marlow [mailto:marlo...@gmail.com] | Sent: 09 January 2014 08:39 | To: Simon Peyton Jones; Herbert Valerio Riedel | Cc: ghc-devs@haskell.org | Subject: Re: High-level Cmm code and stack allocation | | On 08/01/2014 10:07, Simon Peyton Jones wrote: | | Can't we just allocate a Cmm area? The address of an area is a | | perfectly well-defined Cmm value. | | What about this idea? | | We don't really have a general concept of areas (any more), and areas | aren't exposed in the concrete Cmm syntax at all. The current semantics | is that areas may overlap with each other, so there should only be one | active area at any point. I found that this was important to ensure | that we could generate good code from the stack layout algorithm, | otherwise it had to make pessimistic assumptions and use too much stack. | | You're going to ask me where this is documented, and I think I have to | admit to slacking off, sorry :-) We did discuss it at the time, and I | made copious notes, but I didn't transfer those to the code. I'll add a | Note. | | Cheers, | Simon | | | Simon | | | -Original Message- | | From: Simon Marlow [mailto:marlo...@gmail.com] | | Sent: 08 January 2014 09:26 | | To: Simon Peyton Jones; Herbert Valerio Riedel | | Cc: ghc-devs@haskell.org | | Subject: Re: High-level Cmm code and stack allocation | | | | On 07/01/14 22:53, Simon Peyton Jones wrote: | | | Yes, this is technically wrong but luckily works. I'd very much | | | like to have a better solution, preferably one that doesn't add | | | any extra overhead. | | | | | __decodeFloat_Int is a C function, so it will not touch the | | | Haskell stack. | | | | This all seems terribly fragile to me. At least it ought to be | | surrounded with massive comments pointing out how terribly fragile | | it is, breaking all the rules that we carefully document elsewhere. | | | | Can't we just allocate a Cmm area? The address of an area is a | | perfectly well-defined Cmm value. | | | | It is fragile, yes. We can't use static memory because it needs to | | be thread-local. This particular hack has gone through several | | iterations over the years: first we had static memory, which broke | | when we did the parallel runtime, then we had special storage in the | | Capability, which we gave up when GMP was split out into a separate | | library, because it didn't seem right to have magic fields in the | | Capability for one library. | | | | I'm looking into whether we can do temporary allocation on the heap | | for this instead. | | | | Cheers, | | Simon | | | | | | Simon | | | | | -Original Message- | | | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf | | | Of Simon Marlow | | | Sent: 07 January 2014 16:05 | | | To: Herbert Valerio Riedel; ghc-devs@haskell.org | | | Subject: Re: High-level Cmm code and stack allocation | | | | | | On 04/01/2014 23:26, Herbert Valerio Riedel wrote: | | | Hello, | | | | | | According to Note [Syntax of .cmm files], | | | | | | | There are two ways to write .cmm code: | | | | | | | | (1) High-level Cmm code delegates the stack handling to | | | | GHC, | | and | | | | never explicitly mentions Sp or registers. | | | | | | | | (2) Low-level Cmm manages the stack itself, and must know | about | | | | calling conventions. | | | | | | | | Whether you want high-level or low-level Cmm is indicated by | | | | the presence of an argument list on a
RE: High-level Cmm code and stack allocation
Oh, ok. Alas, a good chunk of my model of Cmm has just gone out of the window. I thought that areas were such a lovely, well-behaved abstraction. I was thrilled when we came up with them, and I'm very sorry to see them go. There are no many things that I no longer understand. I now have no idea how we save live variables over a call, or how multiple returned values from one call (returned on the stack) stay right where they are if they are live across the next call. What was the actual problem? That functions used too much stack, so the stack was getting too big? But a one slot area corresponds exactly to a live variable, so I don't see how the area abstraction could possibly increase stack size. And is stack size a crucial issue anyway? Apart from anything else, areas would have given a lovely solution to the problem this thread started with! I guess we can talk about this when you next visit? But some documentation would be welcome. Simon | -Original Message- | From: Simon Marlow [mailto:marlo...@gmail.com] | Sent: 10 January 2014 16:24 | To: Simon Peyton Jones; Herbert Valerio Riedel | Cc: ghc-devs@haskell.org | Subject: Re: High-level Cmm code and stack allocation | | There are no one-slot areas any more, I ditched those when I rewrote the | stack allocator. There is only ever one live area: either the old area | or the young area for a call we are about to make or have just made. | (see the data type: I removed the one-slot areas) | | I struggled for a long time with this. The problem is that with the | semantics of non-overlapping areas, code motion optimisations would tend | to increase the stack requirements of the function by overlapping the | live ranges of the areas. I concluded that actually what we wanted was | areas that really do overlap, and optimisations that respect that, so | that we get more efficient stack usage. | | Cheers, | Simon | | On 10/01/2014 15:22, Simon Peyton Jones wrote: | That documentation would be good, yes! I don't know what it means to | say we don't really have a general concept of areas any more. We did | before, and I didn't know that it had gone away. Urk! We can have lots | of live areas, notably the old area (for the current call/return | parameters, the call area for a call we are preparing, and the one-slot | areas for variables we are saving on the stack. | | Here's he current story | https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/StackAreas | | I agree that we have no concrete syntax for talking about areas, but | that is something we could fix. But I'm worried that they may not mean | what they used to mean. | | Simon | | | -Original Message- | | From: Simon Marlow [mailto:marlo...@gmail.com] | | Sent: 09 January 2014 08:39 | | To: Simon Peyton Jones; Herbert Valerio Riedel | | Cc: ghc-devs@haskell.org | | Subject: Re: High-level Cmm code and stack allocation | | | | On 08/01/2014 10:07, Simon Peyton Jones wrote: | | | Can't we just allocate a Cmm area? The address of an area is | | | a | | | perfectly well-defined Cmm value. | | | | What about this idea? | | | | We don't really have a general concept of areas (any more), and | | areas aren't exposed in the concrete Cmm syntax at all. The current | | semantics is that areas may overlap with each other, so there should | | only be one active area at any point. I found that this was | | important to ensure that we could generate good code from the stack | | layout algorithm, otherwise it had to make pessimistic assumptions | and use too much stack. | | | | You're going to ask me where this is documented, and I think I have | | to admit to slacking off, sorry :-) We did discuss it at the time, | | and I made copious notes, but I didn't transfer those to the code. | | I'll add a Note. | | | | Cheers, | | Simon | | | | | | Simon | | | | | -Original Message- | | | From: Simon Marlow [mailto:marlo...@gmail.com] | | | Sent: 08 January 2014 09:26 | | | To: Simon Peyton Jones; Herbert Valerio Riedel | | | Cc: ghc-devs@haskell.org | | | Subject: Re: High-level Cmm code and stack allocation | | | | | | On 07/01/14 22:53, Simon Peyton Jones wrote: | | | | Yes, this is technically wrong but luckily works. I'd very | | | | much like to have a better solution, preferably one that | | | | doesn't add any extra overhead. | | | | | | | __decodeFloat_Int is a C function, so it will not touch the | | | | Haskell stack. | | | | | | This all seems terribly fragile to me. At least it ought to | | | be | | | surrounded with massive comments pointing out how terribly | | | fragile it is, breaking all the rules that we carefully document | elsewhere. | | | | | | Can't we just allocate a Cmm area? The address of an area is | | | a | | | perfectly well-defined Cmm value. | | | | | | It is fragile, yes. We can't use static memory because it
Re: High-level Cmm code and stack allocation
So stack areas are still a great abstraction, the only change is that they now overlap. It's not just about stack getting too big, I've copied the notes I made about it below (which I will paste into the code in due course). The nice property that we can generate well-defined Cmm without knowing explicit stack offsets is intact. What is different is that there used to be an intermediate state where live variables were saved to abstract stack areas across calls, but Sp was still not manifest. This intermediate state doesn't exist any more, the stack layout algorithm does it all in one pass. To me this was far simpler, and I think it ended up being fewer lines of code than the old multi-phase stack layout algorithm (it's also much faster). Of course you can always change this. My goal was to get code that was at least as good as the old code generator and in a reasonable amount of time, and this was the shortest path I could find to that goal. Cheers, Simon e.g. if we had x = Sp[old + 8] y = Sp[old + 16] Sp[young(L) + 8] = L Sp[young(L) + 16] = y Sp[young(L) + 24] = x call f() returns to L if areas semantically do not overlap, then we might optimise this to Sp[young(L) + 8] = L Sp[young(L) + 16] = Sp[old + 8] Sp[young(L) + 24] = Sp[old + 16] call f() returns to L and now young(L) cannot be allocated at the same place as old, and we are doomed to use more stack. - old+8 conflicts with young(L)+8 - old+16 conflicts with young(L)+16 and young(L)+8 so young(L)+8 == old+24 and we get Sp[-8] = L Sp[-16] = Sp[8] Sp[-24] = Sp[0] Sp -= 24 call f() returns to L However, if areas are defined to be possibly overlapping in the semantics, then we cannot commute any loads/stores of old with young(L), and we will be able to re-use both old+8 and old+16 for young(L). x = Sp[8] y = Sp[0] Sp[8] = L Sp[0] = y Sp[-8] = x Sp = Sp - 8 call f() returns to L Now, the assignments of y go away, x = Sp[8] Sp[8] = L Sp[-8] = x Sp = Sp - 8 call f() returns to L Conclusion: - T[old+N] aliases with U[young(L)+M] for all T, U, L, N and M - T[old+N] aliases with U[old+M] only if the areas actually overlap this ensures that we will not commute any accesses to old with young(L) or young(L) with young(L'), and the stack allocator will get the maximum opportunity to overlap these areas, keeping the stack use to a minimum and possibly avoiding some assignments. On 10/01/2014 16:35, Simon Peyton Jones wrote: Oh, ok. Alas, a good chunk of my model of Cmm has just gone out of the window. I thought that areas were such a lovely, well-behaved abstraction. I was thrilled when we came up with them, and I'm very sorry to see them go. There are no many things that I no longer understand. I now have no idea how we save live variables over a call, or how multiple returned values from one call (returned on the stack) stay right where they are if they are live across the next call. What was the actual problem? That functions used too much stack, so the stack was getting too big? But a one slot area corresponds exactly to a live variable, so I don't see how the area abstraction could possibly increase stack size. And is stack size a crucial issue anyway? Apart from anything else, areas would have given a lovely solution to the problem this thread started with! I guess we can talk about this when you next visit? But some documentation would be welcome. Simon | -Original Message- | From: Simon Marlow [mailto:marlo...@gmail.com] | Sent: 10 January 2014 16:24 | To: Simon Peyton Jones; Herbert Valerio Riedel | Cc: ghc-devs@haskell.org | Subject: Re: High-level Cmm code and stack allocation | | There are no one-slot areas any more, I ditched those when I rewrote the | stack allocator. There is only ever one live area: either the old area | or the young area for a call we are about to make or have just made. | (see the data type: I removed the one-slot areas) | | I struggled for a long time with this. The problem is that with the | semantics of non-overlapping areas, code motion optimisations would tend | to increase the stack requirements of the function by overlapping the | live ranges of the areas. I concluded that actually what we wanted was | areas that really do overlap, and optimisations that respect that, so | that we get more efficient stack usage. | | Cheers, | Simon | | On 10/01/2014 15:22, Simon Peyton Jones wrote: | That documentation would be good, yes! I don't know what it means to | say we don't really have a general concept of areas any more. We did | before, and I didn't know that it had gone away. Urk! We can have lots | of live areas, notably the old area (for the current call/return | parameters, the call area for a call we are preparing, and the one-slot | areas for variables we are saving on the stack. | | Here's he current story |
Re: Validating with Haddock
On 10/01/14 10:01, Mateusz Kowalczyk wrote: Hi all, I have now merged in the new parser and new features onto a single branch. I'm having some issues validating with HEAD at the moment (#8661, unrelated problem) but while I get that sorted out, someone might want to try validating with Haddock changes on their own platform. The full branch is at [1]. I have squashed the changes to what I feel is the minimum number of commits until they completely stop making sense. It should apply cleanly on top of current Haddock master branch. The documentation is updated so you can read about what changed. Feel free to ask any questions. I will post again once I can confirm that the branch validates for me without any new test failures. Thanks for your patience. [1]: https://github.com/Fuuzetsu/haddock/tree/new-features This is just a simple follow up to say that the changes don't seem to break anything new on 32-bit Linux. I provide my validate logs before[1] and after[2] Haddock changes. Here's a word of warning: previously, when the mark-up wasn't 100% clear, we'd get a parse error and no documentation for the whole package. The new parser no longer does this and instead does its best to parse and present everything. This means that any Haddock parse failures should be reported as bugs. As you can see in [1], there were some parse failures in the past (look for ‘doc comment parse failed’) and they will now be rendered. This means the documentation might look bad in those places so it's probably worth while visiting those places and having a look. On an upside, at least we now have documentation for those packages. Validation was ran on commit 15a3de1288fe9d055f3dc92d554cb59b3528fa30 including #8661 fixes. Here's the relevant tail of the logs: Unexpected results from: TEST=lazy-bs-alloc T1969 T3064 T4801 T3294 T5498 haddock.Cabal haddock.compiler haddock.base OVERALL SUMMARY for test run started at Fri Jan 10 12:45:39 2014 GMT 0:17:23 spent to go through 3861 total tests, which gave rise to 15072 test cases, of which 11547 were skipped 28 had missing libraries 3432 expected passes 56 expected failures 0 caused framework failures 0 unexpected passes 9 unexpected failures Unexpected failures: deriving/should_fail T5498 [stderr mismatch] (normal) perf/compiler T1969 [stat too good] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T3294 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) perf/should_run lazy-bs-alloc [stat too good] (normal) gmake[2]: Leaving directory `/home/shana/programming/ghc/testsuite/tests' gmake[1]: Leaving directory `/home/shana/programming/ghc/testsuite/tests' == Start post-testsuite package check Timestamp 2014-01-10 12:45:36.897842164 UTC for /home/shana/programming/ghc/bindisttest/install dir/lib/ghc-7.7.20140109/package.conf.d/package.cache Timestamp 2014-01-10 12:45:36 UTC for /home/shana/programming/ghc/bindisttest/install dir/lib/ghc-7.7.20140109/package.conf.d (older than cache) using cache: /home/shana/programming/ghc/bindisttest/install dir/lib/ghc-7.7.20140109/package.conf.d/package.cache == End post-testsuite package check --- Oops! Looks like you have some unexpected test results or framework failures. Please fix them before pushing/sending patches. --- The failures are the same in both logs. Thanks! [1]: http://fuuzetsu.co.uk/misc/segfix [2]: http://fuuzetsu.co.uk/misc/segfixhaddock -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Folding ghc/testsuite repos *now*, 2nd attempt (was: Repository Reorganization Question)
+1 from me as well. On Thu, Jan 9, 2014 at 4:31 AM, Herbert Valerio Riedel h...@gnu.org wrote: Hello All, It seems to me, there were no major obstacles left unaddressed in the previous discussion[1] (see summary below) to merging testsuite.git into ghc.git. So here's one last attempt to get testsuite.git folded into ghc.git before Austin branches off 7.8 Please speak up *now*, if you have any objections to folding testsuite.git into ghc.git *soon* (with *soon* meaning upcoming Sunday, 12th Jan 2014) A summary of the previous thread so far: - Let's fold testsuite into ghc before branching off 7.8RC - ghc/testsuite have the most coupled commits - make's it a bit easier to cherry pick ghc/testsuite between branches - while being low-risk, will provide empiric value for deciding how to proceed with folding in other Git repos - Proof of concept in http://git.haskell.org/ghc.git/shortlog/refs/heads/wip/T8545 - general support for it; consensus that it will be beneficial and shouldn't be a huge disruption - sync-all is adapted to abort operation if `testsuite/.git` is detected, and advising the user to remove (or move-out-of-the-way) - Concern about broken commit-refs in Trac and other places: - old testsuite.git repo will remain available (more or less) read-only; so old commit-shas will still be resolvable - (old) Trac commit-links which work currently will continue to work, as they refer specifically to the testsuite.git repo, and Trac will know they point to the old testsuite.git - If one doesn't know which Git repo a commit-id is in, there's still the SHA1 look-up service at http://git.haskell.org/ which will search all repos hosted at git.haskell.org for a commit SHA1 prefix. Or alternatively, just ask google about the SHA1. - Binary blobs (a few compiled executables) that were committed by accident and removed right away again are removed from history to avoid carrying around useless garbage in the Git history (saves ~20MiB) - Path names are rewritten to be based in testsuite/, in order to make it easier for Git operations (git log et al.) to follow history for folders/filenames - Old Commit-ids will *not* be written into the rewritten commits' messages in order not to add noise (old commit ids can be resolved via the remaining old testsuite.git repo) [1] http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/3099 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
