Re: Alternative to isTypeLevPoly

find this. > > On Thu, 15 Sept 2022 at 16:36, Krzysztof Gogolewski < > krz.gogolew...@gmail.com> wrote: > >> The type argument to LitRubbish should be a fixed RuntimeRep. If it is >> not, you can file a bug. I have fixed a related bug in f435d55fe969e7. >> >>

Re: Alternative to isTypeLevPoly

Wed, 14 Sept 2022 at 18:40, Csaba Hruska > wrote: > >> Hi, >> Thanks for the tip, I've tried it and it behaves differently than >> isTypeLevPoly. I can get panic when querying the reptype for fixed >> reptypes. That means isTypeLevPoly semantically is not the same as

Re: Alternative to isTypeLevPoly

, wrote: > Hi Csaba, > > I think you want the function typeHasFixedRuntimeRep from GHC.Core.Type. > > Best, > > Sam > > On Wed, 14 Sept 2022 at 18:12, Csaba Hruska > wrote: > >> Hello GHC Devs, >> >> I've noticed that the `isTypeLevPoly` functio

Alternative to isTypeLevPoly

. Is there an alternative to `isTypeLevPoly` in GHC 9.4? Best regards, Csaba Hruska ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Re[2]: Transparently hooking into the STG stack to validate an escape analysis

work will be very valuable in replacing some of > the annoying ticky-based instrumentation ideas! > > Maybe we can have a call some time this or next week to discuss details, > once Sebastian and I are more familiar with the code base? > > Thanks for sticking with the project and doing all

Re: Transparently hooking into the STG stack to validate an escape analysis

Hi, IMO the Cmm STG machine implementation is just too complex for student projects. It's not fun to work with at all. Why did you choose this approach? IMO the escape analysis development and validation would be much smoother and fun when you'd use the external STG interpreter. When you have a

Re: Why and How the External STG interpreter is Useful (Online presentation, Dec 2, Friday, 17:00 UTC)

epping debugger integrated with IDEs via > https://github.com/phoityne/haskell-debug-adapter ? > https://github.com/phoityne/ghci-dap is still quite limited feature-wise. > > On 2021-12-02, at 22:52, Csaba Hruska wrote: > > Hello, > > Today I'll do a presentation about

Re: Why and How the External STG interpreter is Useful (Online presentation, Dec 2, Friday, 17:00 UTC)

Hello, The presentation recording <https://www.youtube.com/watch?v=wt6iCgYmVGA> and slides <https://docs.google.com/presentation/d/1Lmfpwtx_7TbIAGYnSE0HqkawRu75y2GGwbObuu0xYPY/edit?usp=sharing> are available now. Regards, Csaba On Thu, Dec 2, 2021 at 3:52 PM Csaba Hruska wro

Re: Why and How the External STG interpreter is Useful (Online presentation, Dec 2, Friday, 17:00 UTC)

Yes! On Thu, Dec 2, 2021 at 4:04 PM chessai wrote: > Hi, > > Will there be a recording? > > Thanks > > On Thu, Dec 2, 2021, 06:55 Csaba Hruska wrote: > >> It's on Thursday Dec 2 17:00 UTC. (Today) >> Sorry for the confusion. >> >> On Th

Re: Why and How the External STG interpreter is Useful (Online presentation, Dec 2, Friday, 17:00 UTC)

It's on Thursday Dec 2 17:00 UTC. (Today) Sorry for the confusion. On Thu, Dec 2, 2021 at 3:52 PM Csaba Hruska wrote: > Hello, > > Today I'll do a presentation about the external stg interpreter. > If you are interested please join and ask questions. > https://skillsmatter.co

Why and How the External STG interpreter is Useful (Online presentation, Dec 2, Friday, 17:00 UTC)

Hello, Today I'll do a presentation about the external stg interpreter. If you are interested please join and ask questions. https://skillsmatter.com/meetups/13654-haskell-stg-interp Regards, Csaba Hruska Abstract: Haskell: Why and How the External STG Interpreter is Useful The external STG

Haskell program introspection tooling development.

Hello, I'm using the external STG interpreter to introspect the runtime behaviour of Haskell programs. Lately I've added an initial call-graph construction feature that I plan to refine further. https://twitter.com/csaba_hruska/status/1417486380536582151 Is there anyone who has dynamic analysis

Re: abstract interpreter for GHC Core or STG

rimops and RTS/FFI features were supported by the GHC Core supercompiler? On Wed, Jun 9, 2021 at 12:26 AM Csaba Hruska wrote: > The external STG interpreter implements the RTS semantics and features, so > if we apply the calculating correct compiler method to the external STG > interpret

Re: abstract interpreter for GHC Core or STG

uld this be used to generate the rts automatically? I’m intrigued / > would like to understand what you’re envisioning design wise for that leg. > > On Tue, Jun 8, 2021 at 5:34 PM Csaba Hruska > wrote: > >> Cmm is too low level, I've implemented the primops in haskell in a high

Re: abstract interpreter for GHC Core or STG

currency, STM, >> etc, it would be something of a challenge. The AAM story could be >> interesting… >> >> >> >> Simon >> >> >> >> *From:* ghc-devs *On Behalf Of *Csaba >> Hruska >> *Sent:* 07 June 2021 15:18 >> *To:* GHC

Re: abstract interpreter for GHC Core or STG

a JIT?!?) >> >> An important question is : what questions do you want the abstract >> interpreter to suport? >> >> On Mon, Jun 7, 2021 at 10:19 AM Csaba Hruska >> wrote: >> >>> Hello, >>> >>> I wonder if there was an attemp

abstract interpreter for GHC Core or STG

/Haskell evolution. Regards, Csaba Hruska ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: External STG Interpreter blog post

of interest to folk who have been thinking about “fat interface > files”. > > > Simon > > > > *From:* ghc-devs > *On Behalf Of *Csaba Hruska > *Sent:* 10 April 2021 11:49 > *To:* GHC developers > *Subject:* External STG Interpreter blog post > > >

External STG Interpreter blog post

Hello, I've written a blog post about GHC-WPC's external stg interpreter. https://www.patreon.com/posts/external-stg-49857800 Feedback is welcome. Cheers, Csaba ___ ghc-devs mailing list ghc-devs@haskell.org

Re: Weekly show & tell video meeting

Hello, The Haskell & Compilers Show & Tell meeting will be on Sunday 19:00 UTC via google meet. https://meet.google.com/qst-sfid-feu Cheers, Csaba On Mon, Feb 15, 2021 at 5:18 PM Csaba Hruska wrote: > What time works for you? > My schedule is flexible. > > On Mon, Feb

Re: Weekly show & tell video meeting

What time works for you? My schedule is flexible. On Mon, Feb 15, 2021 at 5:11 PM Edward Kmett wrote: > I'd be happy to go with one and see how it goes and plan from there if > that works for you. > > -Edward > > On Mon, Feb 15, 2021 at 7:06 AM Csaba Hruska > wrote: >

Weekly show & tell video meeting

Hello, Would you be interested in a weekly show & tell video meeting? The topic would be Haskell & compilers in general. Either GHC or non-GHC related. Regards, Csaba ___ ghc-devs mailing list ghc-devs@haskell.org

Re: remAddr# primop inconsistency

Great, thanks! On Sat, Feb 6, 2021 at 5:04 PM Ben Gamari wrote: > Csaba Hruska writes: > > > Hello, > > > > I've discovered that the remAddr# primop documentation is inconsistent > with > > the implementation. > > According to the docs (primops.

remAddr# primop inconsistency

(mo_wordURem platform) > WordRemOp -> \args -> opTranslate args (mo_wordURem platform) > IntRemOp -> \args -> opTranslate args (mo_wordSRem platform) > Which one is correct, the docs or the implementation? Regards, Csaba Hruska ___ ghc-de

Re: presentation: Next-gen Haskell Compilation Techniques

program analysis. Or maybe you can find ways to > make them more resilient. > > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Csaba > Hruska > *Sent:* 11 January 2021 12:19 > *To:* Sebastian Graf > *Cc:* GHC developers > *Subject:* Re: presentation

Re: presentation: Next-gen Haskell Compilation Techniques

s. > > I only read the slides, apologies if some of my points were invalidated by > something you said. > > Keep up the good work! > Cheers, > Sebastian > > [1] https://gitlab.haskell.org/ghc/ghc/-/issues/19113 > [2] > https://www.microsoft.com/en-us/research/wp-con

presentation: Next-gen Haskell Compilation Techniques

Hello, I did an online presentation about Haskell related (futuristic) compilation techniques. The application of these methods is also the main motivation of my work with the grin compiler project and ghc-wpc. video: https://www.youtube.com/watch?v=jyaR8E325ok slides:

WebUI for GHC/Haskell tooling (eventlog)

Hello, I've written a blog post about my WebUI based eventlog related tool. It is also related to eventlog2html and ghc-debug. I'm interested in your opinion and ideas related to ghc debug/profiling tooling. If you have time please read the post and it

Re: Creative ideas on how to debug heap corruption

well before the program >> actually crashes. >> >> >> On Mon, Aug 31, 2020 at 11:08 AM Csaba Hruska >> wrote: >> >>> Dump the whole heap into file during GC traversal or taking the whole >>> allocated area. hmm, maybe this is the same as co

Re: Creative ideas on how to debug heap corruption

Dump the whole heap into file during GC traversal or taking the whole allocated area. hmm, maybe this is the same as core dump. On Mon, Aug 31, 2020 at 11:00 AM Ben Lippmeier wrote: > > > > On 31 Aug 2020, at 5:54 pm, Moritz Angermann > wrote: > > > > If anyone has some create ideas, I'd love

Re: Introducing GHC whole program compiler (GHC-WPC)

/haskell-gap.pdf - LoCal: A Language for Programs Operating on Serialized Data http://recurial.com/pldi19main.pdf - On fast large-scale program analysis in Datalog https://souffle-lang.github.io/pdf/cc.pdf - ASAP: As Static As Possible memory management https://www.cl.cam.ac

Re: Introducing GHC whole program compiler (GHC-WPC)

ld be > Cmm, not STG—but I think that difference is not that significant here: the > STG-to-Cmm pass is quite mechanical, and STG is mostly just easier to > manipulate. > > tl;dr: Have you considered naming this project GHC-LTO instead of GHC-WPC? > > > Alexis > > O

Introducing GHC whole program compiler (GHC-WPC)

Hello, I've created a whole program compilation pipeline for GHC via STG. Please read my blog post for the details: Introducing GHC whole program compiler (GHC-WPC) <https://www.patreon.com/posts/introducing-ghc-38173710> Regards, Csaba Hruska _

GHC HEAD windows instability

Hello, I built GHC HEAD on windows 10, but some time the build process got stopped due to random crash. But when I restart the build process the error disappears. Is this a known issue? Regards, Csaba *Case A:*

Unique invariants: GHC invocation vs scope?

scope. Is this intentional? Thanks, Csaba Hruska ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC HEAD (Quickest) segfaults during compilation of optparse-applicative

; which I > usually avoid). > > - More reproducers = more tests, which are good. > > Also, when you ask whether this is a known bug on the mailing list it's > effectively the same as just submitting a bug report: either way you don't > search it yourself and ask for other devs to do i

is backport planned for 8.8.X of MR 1304?

Hello, Will MR 1304 be backported to GHC 8.8.X? Thanks, Csaba ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

source-dist from GHC master branch

Hello, I'd like to create a source distribution (source-dist) from GHC git master branch. I tried hadrian (hadrian/build.sh source-dist) and make (make sdist-ghc) but both failed in different ways. Should this work (at all) for any git snapshot? Hadrian successfully built a source dist

GHC 8.8.2 miscompiles program with -fcatch-bottoms

Hello, I've tried to compile GHC from source using -fcatch-bottoms on the stage2. I compiled GHC with having *GhcStage2HcOpts += -fcatch-bottoms* in build.mk. Unfortunately it breaks programs and causes runtime error. I wanted to use this feature in an experiment. My motivation: *I'm working on

Re: DataCon tag value convention

ly not stable across > several runs of the same binary. However, within a single run, it seems to > work. > > - Vlad > > > On 12 Feb 2020, at 21:57, Csaba Hruska wrote: > > > > Hello, > > > > In theory could GHC codegen work if every data constructor in the who

Re: DataCon tag value convention

ich is probably a substantial performance loss. > > Am Mi., 12. Feb. 2020 um 19:58 Uhr schrieb Csaba Hruska < > csaba.hru...@gmail.com>: > >> Hello, >> >> In theory could GHC codegen work if every data constructor in the whole >> program have a globally unique tag va

DataCon tag value convention

Hello, In theory could GHC codegen work if every data constructor in the whole program have a globally unique tag value instead of starting from 1 for each algebraic data type? Would this break any GHC design decision? Regards, Csaba ___ ghc-devs

Re: ADT arguments and Levity Polymorphism

Great, thanks! On Mon, Feb 10, 2020 at 10:30 PM Richard Eisenberg wrote: > > > On Feb 10, 2020, at 8:48 PM, Csaba Hruska wrote: > > Hello, > > Are heap stored ADT's arguments always levity (representation) monomorphic? > > > Yes. > > > *(I guess

ADT arguments and Levity Polymorphism

Hello, Are heap stored ADT's arguments always levity (representation) monomorphic? *(I guess they are otherwise the info table would not be a constant value instead it would be a function that calculates the representation depending on some runtime value.)* Regards, Csaba Hruska

Re: FloatRep and DoubleRep ADT Argument in STG

ons, so a float > parameter undergoes automatic conversion to double as part of the default > argument promotions (see section 6.5.2.2 of the C99 standard).* > Sorry for the confusion. Thanks, Csaba On Wed, Jan 22, 2020 at 10:27 PM Csaba Hruska wrote: > I added Stg and Cmm lint

Re: FloatRep and DoubleRep ADT Argument in STG

I added Stg and Cmm linter to my custom pipeline and they report no errors. On Wed, Jan 22, 2020 at 4:40 PM Csaba Hruska wrote: > Here are the pretty printed STG in GHC syntax: > > *WORKING (DoubleRep): prints 3.14* > > > > > > > > > > > > > >

Re: FloatRep and DoubleRep ADT Argument in STG

; __pkg_ccall [x1 x203]; }; };* Thanks, Csaba On Wed, Jan 22, 2020 at 4:21 PM Csaba Hruska wrote: > Sorry, I should have noted that the gist has a description comment at the > bottom. > > https://gist.github.com/csabahruska/e9e143390c863f7b10b0298a7ae80ac1#gistc

Re: FloatRep and DoubleRep ADT Argument in STG

quot;run into problems"? > What's going wrong? > > It'd be helpful if you could show us your program in STG syntax. > > > Is it valid to use FloatRep argument in a boxed ADT on 64 bit? > > It should be valid, yes. > > I'd also try with `-dstg-lint -dcmm-lint`. > &g

FloatRep and DoubleRep ADT Argument in STG

Hello, I try to use GHC backend via STG. For that reason I build small STG program AST maually. So far the generated programs worked fine (compile/link/run). However I run into problems when a lifted ADT has a FloatRep argument. Interestingly it works for DoubleRep. I'm using GHC 8.6.1 64 bit to

Unboxed Tuple in a single STG variable

Hello, Can an STG variable (Id) store a whole unboxed tuple value? Or is it required to decompose a returned unboxed value immediately by using an StgCase expression? If so, then is it correct that the STG variables can store values only from the following types: Addr, Float, Double, Int, Word,

Re: is Unlifted Type == Primitive Type?

i is out of date, do you think you could update it? > > Thanks! > Richard > > On Jan 20, 2020, at 9:45 AM, Csaba Hruska wrote: > > Hello, > > According to GHC Wiki > <https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/type-type#Classifyingtypes> > it

is Unlifted Type == Primitive Type?

Hello, According to GHC Wiki it seems that only primitive types can be unlifted. Is this true in general? (i.e. no user type can be unlifted) [image: image.png] Does the Stg to Cmm codegen support

Re: Typo in closure name in rts/Prelude.h

Sorry, I messed up the first link. It meant to be *base_GHCziWeak_runFinalizzerBatch_closure* <https://gitlab.haskell.org/ghc/ghc/blob/master/rts/Prelude.h#L30> On Sun, Dec 15, 2019 at 1:15 PM Csaba Hruska wrote: > Hello, > > Could you confirm if *base_GHCziWeak_rrts/win32/libHSb

Typo in closure name in rts/Prelude.h

Hello, Could you confirm if *base_GHCziWeak_rrts/win32/libHSbase.def_closure* is a typo in rts/Prelude.h? I guess it is a typo because *base_GHCziWeak_runFinalizerBatch_closure* does exists in base/GHC/Weak.hs.

.hie files for pre-installed GHC libraries

Hi, Is it planned to include the .hie files of the base and other libraries in the GHC binary download package? Regards, Csaba Hruska ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Quick Q: do all FFI (non-primop) calls involve State# and RealWorld?

Hi, I've also observed that in the final lowered STG the State# is always passed to effectful primops and FFI calls, but the returning new State# is removed from the result type. The State# has VoidRep representation in in cmm, so no register gets allocated for it and eventually the State#

Re: ByteArray# as a foreign import argument?

Sorry, maybe I got it wrong. Are you asking if is there any package that passes ByteArrays via FFI? On Thu, Oct 10, 2019 at 8:54 PM Csaba Hruska wrote: > It's a primitive type. > > https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/prelude/primops.txt.pp#L1388 > https://gitlab

Re: ByteArray# as a foreign import argument?

It's a primitive type. https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/prelude/primops.txt.pp#L1388 https://gitlab.haskell.org/ghc/ghc/wikis/commentary/prim-ops Cheers, Csaba On Thu, Oct 10, 2019 at 8:16 PM Shao, Cheng wrote: > Hello devs, > > I've been trying to figure out how to pass

Re: typePrimRep invariants

I've got the answer at #ghc irc channel. With resultIsLevPoly it is possible to filter out the problematic types. Regards, Csaba On Fri, Nov 30, 2018 at 11:08 PM Csaba Hruska wrote: > Is this problem related to the following? > >> {- Note [Error and friends have an "o

Re: Writing a simple Core evaluator, having trouble with name lookups

that'll > require more handling so I'll probably need more knowledge of classes > anyway. > > So I'm wondering whether at the STG phase all classes have been > abstracted away and we really do only deal with lambdas, lets and > cases? I didn't see any class-specific code in y

Re: Writing a simple Core evaluator, having trouble with name lookups

The package name + module name is always unique in every Haskell program, module names can not be duplicated in a package and package names are unique also. There are 2 kinds of identifiers, local and exported. You can construct a whole program unique name for: - exported identifier with

Re: typePrimRep invariants

gt; a > undefined :: forall (v :: RuntimeRep) (a :: TYPE v). a > Notice the runtime-representation polymorphism. This ensures that > "error" can be instantiated at unboxed as well as boxed types. > This is OK because it never returns, so the return type is irrelevant. >

typePrimRep invariants

Hi, I'd like to export the PrimRep of every binder and data con from Haskell modules. I have a modified GHC 8.6 which serializes the PrimRep for every binder during the compilation. It uses the *typePrimRep* function. When my customised GHC compiles the base library it always thows the following

Re: Writing a simple Core evaluator, having trouble with name lookups

I'm aware that unique names are unique in a GHC invocation. But my statements sill holds. On Fri, Nov 30, 2018 at 7:20 PM Ben Gamari wrote: > Csaba Hruska writes: > > > Hi Ben, > > > > I thought that it is possible to rely on unique values *in case of non &

Re: Writing a simple Core evaluator, having trouble with name lookups

Hi Ben, I thought that it is possible to rely on unique values *in case of non exported Ids* because they are local to a specific module and can not appear in expressions in other modules because they are not exported. Do I miss something? Cheers, Csaba On Fri, Nov 30, 2018 at 2:59 PM Ben

Re: Writing a simple Core evaluator, having trouble with name lookups

Just to clarify, for exported names ignore the unique value completely and use module name + occurrence name. In your case that is the idStableName field. For non exported names use idStableName + idUnique. I'll also check your project. Cheers, Csaba On Fri, Nov 30, 2018 at 12:23 PM Christopher

Re: Writing a simple Core evaluator, having trouble with name lookups

Hi! I can give some info for your second question. GHC uses wired-in id's for the primitives and some other AST construction too. Read more here: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/WiredIn Regarding the names you can use qualified (module + occ) names for exported ids.

Re: StgRhsClosure freevar and argument name duplicates

I have a question. Do unique names have SSA semantic in STG? Can multiple (StgRec/StgNonRec) binding id have the same unique value? On Tue, Nov 6, 2018 at 5:10 PM Csaba Hruska wrote: > https://ghc.haskell.org/trac/ghc/ticket/15867 > > On Tue, Nov 6, 2018 at 4:47 PM Csaba Hruska

Re: StgRhsClosure freevar and argument name duplicates

https://ghc.haskell.org/trac/ghc/ticket/15867 On Tue, Nov 6, 2018 at 4:47 PM Csaba Hruska wrote: > Ok, I'll open a ticket. > To reproduce: > >1. patch GHC head: *git apply StgScopeCheck.patch* >2. make sure every compiled stg is linted: *add -dstg-lint* to &g

Re: StgRhsClosure freevar and argument name duplicates

Correction: I've also noticed that there are two Main.main top-level binders in the generated STG with different uniques. On Tue, Nov 6, 2018 at 12:19 PM Csaba Hruska wrote: > I've also noticed that there are two Main.main top-level binders in the > generated STG with different u

Re: StgRhsClosure freevar and argument name duplicates

mon Peyton Jones wrote: > I think top level names should be unique in occ-names; because those > occ-names generate the symbols in the binary. > > > > Simon > > > > *From:* Csaba Hruska > *Sent:* 06 November 2018 11:01 > *To:* Simon Peyton Jones > *Cc:* gh

Re: StgRhsClosure freevar and argument name duplicates

learly wrong. > > > > But I do wonder if it could perhaps be something to do with your branch? > > > > Thanks > > > > Simon > > > > *From:* Csaba Hruska > *Sent:* 05 November 2018 16:33 > *To:* Simon Peyton Jones > *Cc:* ghc-devs@haske

Re: StgRhsClosure freevar and argument name duplicates

Correction! The problem happens in integer-gmp: https://github.com/ghc/ghc/blob/master/libraries/integer-gmp/src/GHC/Integer/Type.hs#L761-L770 On Mon, Nov 5, 2018 at 5:27 PM Csaba Hruska wrote: > An example for the duplication please check the divModInteger > <https://github.com/ghc

Re: StgRhsClosure freevar and argument name duplicates

ype.Jn# {-r5814-} dt.s84150 {-s84150-} -> $j.s84128 {-s84128-} -1# } }} On Mon, Nov 5, 2018 at 2:08 PM Simon Peyton Jones wrote: > I don’t think there should be duplicates in either. Do you have a test > case that shows duplicates? > > > > Simon > &

Re: StgRhsClosure freevar and argument name duplicates

at all. And the scope checker function (addInScopeVars) does not check for duplicates. Any thoughts? Cheers, Csaba On Sat, Nov 3, 2018 at 9:53 AM Csaba Hruska wrote: > Hi, > > Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) contain > duplicates? > > Cheers

StgRhsClosure freevar and argument name duplicates

Hi, Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) contain duplicates? Cheers, Csaba data GenStgRhs bndr occ = StgRhsClosure CostCentreStack -- CCS to be attached (default is CurrentCCS) StgBinderInfo -- Info about how this binder is used

Re: multiple top level Main.main binders in STG

{-021-}} *Main.main {-0101-}* = closure (F:) (B: void.040 {-040-}) { Main.main3 {-r16518-} GHC.Prim.void# {-021-}} On Fri, Nov 2, 2018 at 11:18 PM Ben Gamari wrote: > Csaba Hruska writes: > > > Hello, > > > > I added an STG exporter to my modified GHC

Re: multiple top level Main.main binders in STG

P.S. I'd like to emphasize that this is produced by GHC and GHC's codegen compiles it properly to a working executable. On Fri, Nov 2, 2018 at 10:18 PM Csaba Hruska wrote: > Hello, > > I added an STG exporter to my modified GHC to do experiments with the STG > representation of the

multiple top level Main.main binders in STG

Hello, I added an STG exporter to my modified GHC to do experiments with the STG representation of the program. I noticed that there are multiple top-level binders for *Main.main* function. Is this a convention or a bug? Regards, Csaba Hruska Here is an example code snippet of the exported STG

Re: Using GHC Core as a Language Target

t; - Dive into GHC: Targeting Core <http://www.stephendiehl.com/posts/ghc_03.html> Cheers, Csaba Hruska On Thu, Oct 25, 2018 at 8:51 PM Ara Adkins wrote: > Heya, > > Those are exactly the kind of pointers I was hoping for. Thanks Iavor. > > I’m sure I’ll have mor

GHC Core / STG to supercombinators

be the easiest way to do this? (i.e. via *CoreToDo* or custom calls for the simplifying functions) Or would it be simpler to generate top level (lazy) functions from STG? Regards, Csaba Hruska ___ ghc-devs mailing list ghc-devs@haskell.org http