Re: Stg-lint and bootstrapping (fails?)
Indeed, it does not happen on fresh HEAD, I'll have to dig deeper.
Maybe it is related to my changes, but I only changed Stg-related
stuff. Join-points are a Core thing, right?
Anyway, I'll keep you informed if I figure it out.
Cheers,
Gabor
On 8/22/17, Simon Peyton Jones wrote:
> Is this with HEAD? I have an up to date HEAD, and with your command line I
> don't get those warnings. But I do get the OccAnal warnings, so it's not
> that the warnings are being suppressed.
>
> I'm not sure how to reproduce.
>
> Does this happen on anything smaller? Eg. on a testsuite program (you'll
> need to switch off the -dno-debug-output)?
>
> Simon
>
> | -Original Message-
> | From: Gabor Greif [mailto:ggr...@gmail.com]
> | Sent: 22 August 2017 09:57
> | To: Simon Peyton Jones ; ghc-devs | d...@haskell.org>
> | Subject: Re: Stg-lint and bootstrapping (fails?)
> |
> | On 8/21/17, Gabor Greif wrote:
> | > Hi Simon,
> | >
> | > for me it happens on many files that are compiled with
> | >
> | > $ make GhcStage2HcOpts="-O1 -g"
> | >
> | > while the stage1 compiler is active.
> | >
> | > Tomorrow I can add a concrete invocation.
> |
> | Here is it:
> |
> | "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m
> -Wall
> | -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -
> | Iincludes/dist-derivedconstants/header
> | -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3
> -hide-all-packages
> | -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -
> | icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci
> -
> | icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -
> | icompiler/nativeGen -icompiler/parser -icompiler/prelude -
> | icompiler/profiling -icompiler/rename -icompiler/simplCore -
> | icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -
> | icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils
> -
> | icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -
> | icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -
> | Icompiler/. -Icompiler/parser -Icompiler/utils
> -Icompiler/../rts/dist/build
> | -Icompiler/stage2 -optP-DGHCI -optP-include -
> | optPcompiler/stage2/build/./autogen/cabal_macros.h
> | -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id
> | directory-1.3.0.2 -package-id process-1.6.1.0 -package-id
> | bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id
> | time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 -
> | package-id filepath-1.4.1.2 -package-id template-haskell-2.12.0.0
> -package-
> | id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id
> | ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3
> -package-id
> | unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall -fno-warn-name-shadowing
> -
> | this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -
> | DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing
> | -O1 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir
> | compiler/stage2/build -hidir compiler/stage2/build -stubdir
> | compiler/stage2/build -dynamic-too -c compiler/typecheck/TcEvidence.hs
> -o
> | compiler/stage2/build/TcEvidence.o -dyno
> | compiler/stage2/build/TcEvidence.dyn_o
> | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_soeO]
> | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_soeN]
> | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_sosq]
> | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_soxX]
> | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_soy2]
> | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_soy9]
> | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_soyw]
> | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_sowZ]
> | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_sovR]
> | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_sovx]
> | WARNING: file compiler/simplCore/SimplCore.hs, line 700
> |Simplifier bailing out after 4 iterations [721, 479, 80, 4]
> | Size = {terms: 8,035, types: 8,864, coercions: 1,129, joins: 0/96}
> | WARNING: file compiler/simplCore/OccurAnal.hs, line 2163 Just 3 []
> | WARNING: file compiler/simplCore/OccurAnal.hs, line 2163 Just 3 []
> | WARNING: file compiler/simplCore/OccurAnal.hs, line 2163 Just 3 []
> |
RE: Alex install failure
Simon Peyton Jones writes: > | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by > | any chance? > > Direct hit! (for the shot in the dark). Yes it's NFS mounted I think. > So what? Hi Simon, Sorry for the rather belated reply; I was knocked off my feet for a few days by a rather nasty tetanus vaccination. Anyways, I have a patch which I suspect will help. It seems that some NFS implementations incur a rather long delay (order of seconds) between the time a file handle is closed and an open flock lock on the handle being released. I suspect this delay won't exist in cases where we explicitly funlock before closing the file handle. I have implemented this in wip/ghc-pkg-locking. Do you think you could give this branch a try? If it still fails then we'll have to try to debug things in-situ. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs
I’m keen NOT to introduce these layers of indirection. I think they make the code harder to understand. Can you give an example function or two, and what it would look like under the different approaches. (1)-(3) appears to be three different approaches, but I don’t think that’s what you intend. I think there are only two: add the indirection layer or not? S From: Shayan Najd [mailto:sh.n...@gmail.com] Sent: 23 August 2017 13:26 To: ghc-devs@haskell.org Cc: Simon Peyton Jones ; Alan & Kim Zimmerman Subject: Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs In this thread, I am going to raise a topic for discussion. Please share your opinions and related experiences. Evaluation of type families within HsSyn ASTs, such as `PostTc`, with a fixed phase index, such as `GhcPs`, gives us distinct ASTs at the *compile-time*. However, when programming with these ASTs, we use patterns, such as `HsMultiIf :: PostTc p Type -> [LGRHS p (LHsExpr p)] -> HsExpr p` that are shared among phases. We can (1) introduce a layer of abstraction providing a set of type and pattern synonyms specific to each phase, such as `PsMultiIf :: [LPsGRHS LPsExpr] -> PsExpr`; and (2) updating code working on ASTs of specific phase to use the interface specific to the phase, such as by changing prefixes from `Hs` to `Ps` and by removing unused variables and placeholders; and (3) leaving untouched code working uniformly on ASTs of different phases (i.e., the generic functions in Trees that Grow terminology), such as the existing functions whose types are polymorphic on phase index. Some comments: - It can be done gradually and smoothly: we add three separate files in HsSyn (per each phase) containing the phase-specific interfaces, and gradually import them and do the changes per module. - Using the interfaces is optional: code using the current method (e.g., using `HsMultiIf`) should work just fine. - It introduces a layer of indirection and three more files to maintain. - It makes code working on HsSyn ASTs, such as the renamer, appear cleaner as placeholders and similar machinery are abstracted away by the interfaces (e.g., no need to import bits and pieces of `HsExtension`) - In theory, there should be zero impact on GHC's runtime performance. I am myself undecided about its benefit-cost ratio, but willing to at least implement the phase-specific interfaces. For me, abstracting away all the `PostRn` stuff, `Out` prefixed constructors, and dummy placeholders from the front-end code is the most valuable. Yours, Shayan ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs
>
> (1)-(3) appears to be three different approaches, but I don’t think that’s
> what you intend. I think there are only two: add the indirection layer or
> not?
(1)-(3) are just steps when we do choose to add the indirection layer: add
the layer, and do the changes when desired.
If we choose to not to add the indirection layer, nothing needs to be
changed and the internals of the encoding (`PostTc`, place holders, etc)
remain visible in the code.
Can you give an example function or two, and what it would look like under
> the different approaches.
For example, the function clause
> rnExpr (HsMultiIf _ty alts)
> = do { (alts', fvs) <- mapFvRn (rnGRHS IfAlt rnLExpr) alts
> ; return (HsMultiIf placeHolderType alts', fvs) }
becomes
> rnExpr (PsMultiIf alts)
> = do { (alts', fvs) <- mapFvRn (rnGRHS IfAlt rnLExpr) alts
> ; return (RnMultiIf alts', fvs) }
I hope it clarifies what I mean a bit.
There is always a choice between how distinct we want the phases to be.
The more distinct they are, the higher static guarantees. The code also
gets more clear in a way, e.g. `RnMultiIf` is talking about a renamed
expression, `PsMultiIf` about a parsed expression, while `HsMultiIf` is
talking about an expression of any phase.
At the same, distinctness means more work for the programmer.
Also, such distinction sometimes implies a pedagogic burdon, as readers
should now learn about more than one AST. However, this burden is very low
here thanks to the prefixing convention: `PsMultiIf` and `RnMultiIf` are
easily understood to represent the same thing in different phases.
Finally, such distinctions often lead to code duplication. But in our case,
Trees that Grow machinery saves us from such duplication, e.g., we have the
same base ASTs and we can write generic programmers over the bases ASTs
anytime we want (point/step (3) above).
Thanks,
Shayan
On Thu, Aug 24, 2017 at 3:35 PM, Simon Peyton Jones
wrote:
> I’m keen NOT to introduce these layers of indirection. I think they make
> the code harder to understand.
>
>
> Can you give an example function or two, and what it would look like under
> the different approaches.
>
>
>
> (1)-(3) appears to be three different approaches, but I don’t think that’s
> what you intend. I think there are only two: add the indirection layer or
> not?
>
>
>
> S
>
>
>
> *From:* Shayan Najd [mailto:sh.n...@gmail.com]
> *Sent:* 23 August 2017 13:26
> *To:* ghc-devs@haskell.org
> *Cc:* Simon Peyton Jones ; Alan & Kim Zimmerman <
> alan.z...@gmail.com>
> *Subject:* Discussion: Static Safety via Distinct Interfaces for HsSyn
> ASTs
>
>
>
> In this thread, I am going to raise a topic for discussion. Please share
> your opinions and related experiences.
>
>
>
> Evaluation of type families within HsSyn ASTs, such as `PostTc`, with a
> fixed phase index, such as `GhcPs`, gives us distinct ASTs at the
> *compile-time*.
>
> However, when programming with these ASTs, we use patterns, such as `HsMultiIf
> :: PostTc p Type -> [LGRHS p (LHsExpr p)] -> HsExpr p` that are shared
> among phases.
>
> We can
>
> (1) introduce a layer of abstraction providing a set of type and pattern
> synonyms specific to each phase, such as `PsMultiIf :: [LPsGRHS LPsExpr]
> -> PsExpr`; and
>
> (2) updating code working on ASTs of specific phase to use the interface
> specific to the phase, such as by changing prefixes from `Hs` to `Ps` and
> by removing unused variables and placeholders; and
>
> (3) leaving untouched code working uniformly on ASTs of different phases
> (i.e., the generic functions in Trees that Grow terminology), such as the
> existing functions whose types are polymorphic on phase index.
>
>
>
> Some comments:
>
>
>
> - It can be done gradually and smoothly: we add three separate files in
> HsSyn (per each phase) containing the phase-specific interfaces, and
> gradually import them and do the changes per module.
>
> - Using the interfaces is optional: code using the current method (e.g.,
> using `HsMultiIf`) should work just fine.
>
> - It introduces a layer of indirection and three more files to maintain.
>
> - It makes code working on HsSyn ASTs, such as the renamer, appear cleaner
> as placeholders and similar machinery are abstracted away by the interfaces
> (e.g., no need to import bits and pieces of `HsExtension`)
>
> - In theory, there should be zero impact on GHC's runtime performance.
>
>
>
> I am myself undecided about its benefit-cost ratio, but willing to at
> least implement the phase-specific interfaces.
>
> For me, abstracting away all the `PostRn` stuff, `Out` prefixed
> constructors, and dummy placeholders from the front-end code is the most
> valuable.
>
>
>
> Yours,
>
> Shayan
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
