Feedback on applying implicit exceptions wanted

I'm currently working out ideas for potential optimizations in pattern matching compilation for GHC. While I think the theory works out fine in regards to exceptions I would like feedback on the possible implications. Trac ticket with details is here:

Asserting vars with different Uniques represent the same Object

My core questions are: * Should variables representing the same thing always have the same unique? * If not how can one assert they actually represent the same thing? Working on the pattern matching code I came across this assertion: > ASSERT(tvs1 `equalLength` ex_tvs )

Re: Re: potential for GHC benchmarks w.r.t. optimisations being incorrect

Joachim Breitner schrieb: This runs on a dedicated physical machine, and still the run-time numbers were varying too widely and gave us many false warnings (and probably reported many false improvements which we of course were happy to believe). I have since switched to measuring only dynamic

Re: Basic Block Layout in the NCG

rocedure mapping using cache line coloring (https://doi.org/10.1145/258915.258931) ~kavon On Sat, 2018-05-05 at 21:23 +0200, Andreas Klebinger wrote: Does anyone have good hints for literature on basic block layout algorithms? I've run into a few examples where the current algorithm falls apa

Basic Block Layout in the NCG

Does anyone have good hints for literature on basic block layout algorithms? I've run into a few examples where the current algorithm falls apart while working on Cmm. There is a trac ticket https://ghc.haskell.org/trac/ghc/ticket/15124#ticket where I tracked some of the issues I ran into. As

Combining Bag/OrdList?

We have OrdList which does: Provide trees (of instructions), so that lists of instructions can be appended in linear time. And Bag which claims to be: an unordered collection with duplicates However the actual implementation of Bag is also a tree if things. Given that we have snocBag, consBag

Re: Combining Bag/OrdList?

Bag, then we are free to improve the implementation of Bag in the future so that it doesn’t preserve order under the hood (e.g, use a hash table). So, I personally think it’s useful to have around. Sent from my phone. Andreas Klebinger <mailto:klebinger.andr...@gmx.at> Samstag, 2. Juni

Looking for GSoC Mentor

Hello Everyone, I'm looking for a mentor for a GSoC Project/Proposal. The whole idea revolves around: * Getting hot path information from static analysis and user annotations. * Making sure it's not destroyed by optimization passes. * Using it to generate better code where applicable. See also:

PSA: You likely want to use -O2 for the stage1 compiler.

I've wondered for a good while if using O2 on stage1 might be worth it. So I did some measurements and it should be worth it for most cases. For a single "quick" flavour build they are more or less on equal footing. If you rebuild stage2 multiple times reusing stage1 it will be faster. If you

Re: Compile times: Average vs worst case runtime

ave to see how well the edge/block ratio correlates with compile time blowups. If we can use that to rule out the really bad cases then (1) should be fine. If not I will have to come back to the question. Cheers Andreas Simon | -Original Message- | From: ghc-devs On Behalf

Compile times: Average vs worst case runtime

Hello Devs, I developed a patch improving on GHC's code layout during GSoC: https://ghc.haskell.org/trac/ghc/ticket/15124 The gains are pretty nice with most library benchmarks showing improvments in the 1-2% range or more. Even compile times went down comparing head vs stage2 built with,

Re: Compile times: Average vs worst case runtime

compile time for regular code and rerun benchmarks to make sure I've not introduced regressions. But if it holds up we should at least enable it at O1/O2. Depending how compile times are for regular code maybe for -O0 as well. Cheers Andreas Andreas Klebinger schrieb: Simon Peyton Jones

CI failures on OSX

Hello devs, OSX CI seems to have testsuite failures since at least 44ba66527ae2 (but likely caused by something else) and started sometime after 966aa7818222

Validate on master broken.

Hello Devs, it seems Simons patch "Smarter HsType pretty-print for promoted datacons" broke ./validate. I discovered that there were two copies of the PromotionFlag type (a boolean, with helpfully named data cons), one in IfaceType and one in HsType. So I combined into one,

Re: Considerations for Control flow hint implementation.

. And AltCon isn't used for anything else Simon *From:*ghc-devs *On Behalf Of *Andreas Klebinger *Sent:* 30 November 2018 11:37 *To:* ghc-devs@haskell.org *Subject:* Considerations for Control flow hint implementation. Hello Devs, I've started thinking about the implementation of https

Considerations for Control flow hint implementation.

kind of performance boost? Cheers, Andreas Klebinger ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: nofib output difference

I fear that one is my fault. This should fix it: https://phabricator.haskell.org/D5426 I did not want to add a large binary file to the repo so instead compress generated the out file during boot. Which used to work well on my box. However make boot also creates the dependency files that

Re: split_marker crash

up in a hour or two and will merge it after it validates. Cheers, Andreas Ben Gamari schrieb: Andreas Klebinger writes: Hello, I'm fine with reverting for now. But could you give me a way to reproduce this error? I've not seen crashes on either linux and windows in various configs. I susp

Re: split_marker crash

Hello, I'm fine with reverting for now. But could you give me a way to reproduce this error? I've not seen crashes on either linux and windows in various configs. Cheers, Andreas Ben Gamari schrieb: Simon Peyton Jones via ghc-devs writes: OK I have verified that * This

Re: Windows release quality

Just to make this clear it's not my intention to blame anyone or point fingers. Given the resources at hand I think Phyx and you have done an amazing job so far to keep things working! The core of the issue is that if someone sits down and installs a "stable" GHC today he will either get a

Windows release quality

Hello Devs, After running into #16408 today I realized there is as of yet no released bindist of the 8.6 series which I would consider stable for windows. GHC 8.6.1 and 8.6.2 had a series of critical bugs which applied to multiple platforms: https://gitlab.haskell.org/ghc/ghc/issues/16408 GHC

Getting a profiled GHC with hadrian.

Hello Devs, What's the proper way to get a profiled GHC in hadrian? I tried hadrian/build.cabal.sh -j8 --flavour=Prof but that didn't work out: $ _build/stage1/bin/ghc.exe +RTS -p ghc.exe: the flag -p requires the program to be built with -prof ghc.exe: ... What am I doing wrong

Re: Thoughts on the Contributing page

On hadrian: Documentation will eventually catch up as more people use hadrian but imo things that need to be supported are: - Some workflows: * make fast * ./validate * make EXTRA_HC_OPTS="..." - On windows build.bat defaults to stack which I think has never worked on my box. - It's

Re: Container type classes

ghc-devs-requ...@haskell.org schrieb: Hello, I think refactoring to use consistent naming is a good idea, but I am not sure about the class idea. To see if it is viable, we should list the types in question and the operations we'd like to overload. I find that with containers there tend to be

Overloaded names for Map/Set?

Hello devs, I would appreciate feedback on the idea in https://gitlab.haskell.org/ghc/ghc/merge_requests/934 Maps/Sets in GHC for the most part offer the same basic functionality but their interfaces differ. In order to make this easier to work with I propose using overloading via IsSet/IsMap

Workflow question

I your situation I would just create a base commit with the (empty) files you intend to add. Then you should not need to reconfigure to build at least. However it sounds like there is nothing stopping you from just building stage1 with a working base commit, then freezing and iterating on stage2

Is HEAD broken?

Is HEAD broken? I get this error with hadrian: I suspect it's only broken on windows and has to do with MSYS #ifdefs /-\ | Successfully built library 'ghci' (Stage0, way v).  | | Library:

Re: Is HEAD broken?

Upon restarting the build it seems to proceed further. Strange but good enough for me at the moment. Andreas Klebinger schrieb am 15.07.2019 um 00:13: Is HEAD broken? I get this error with hadrian: I suspect it's only broken on windows and has to do with MSYS #ifdefs

GHC: Policy on -O flags?

flags? Tell me what do you think. Cheers, Andreas Klebinger ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Vector registers assumed to be caller or callee-saved?

200, Andreas Klebinger wrote: What you want is not the macro but this function: https://hackage.haskell.org/package/ghc-8.6.5/docs/src/X86.Regs.html#callClobberedRegs whose results depend on the System ABI. Cheers, Andreas Hi all, I'm wondering what GHC assumes about vector registers XMMi, Y

Re: Vector registers assumed to be caller or callee-saved?

What you want is not the macro but this function: https://hackage.haskell.org/package/ghc-8.6.5/docs/src/X86.Regs.html#callClobberedRegs whose results depend on the System ABI. Cheers, Andreas Hi all, I'm wondering what GHC assumes about vector registers XMMi, YMMi, and ZMMi used by the

Re: Compiling binaries of bytecode: ever been considered?

I've heard the idea come up once or twice. But I'm not aware of any efforts going further than that. Christopher Done schrieb am 04.11.2019 um 14:59: Hi all, I was just wondering: has a compiler output mode ever been considered that would dump bytecode to a file, dynamic link to the ghc

Re: Problem with compiler perf tests

Ömer Sinan Ağacan schrieb am 17.11.2019 um 09:22: I think what we should do instead is that once it's clear that the patch did not introduce *accidental* increases in numbers (e.g. in !2100 I checked and explained the increase in average residency, and showed that the increase makes sense and

Re: How to navigate around the source tree?

Hello devs, I also often jump to files. In my case usually using VS Code using Ctr+P as well which searches for files by name. While I can check which folder a file is in in the case of duplicates it is a overhead which this refactor forces onto me. While there are workarounds, both for my case

Re: How to navigate around the source tree?

s an issue at all. But cases where non-unique names cause annoyance do happen from time to time. Hence why I prefer one over the other. (I don't know VS Code enough to help ..) Ömer Andreas Klebinger , 24 Eki 2019 Per, 14:48 tarihinde şunu yazdı: Hello devs, I also often jump to files. In my ca

Unsquashed merge requests

Hello devs, I've recently seen a few MR's make it into master with commits which rather obviously were meant to be squashed. Please look out for this when assigning MRs to marge. Cheers Andreas ___ ghc-devs mailing list ghc-devs@haskell.org

Re: Blocking MVar# primops not performing stack checks?

I just took a look at the implementation and it looks like you are right Cheng. I opened a ticket here: https://gitlab.haskell.org/ghc/ghc/issues/17893 Carter Schonwald schrieb am 02.03.2020 um 06:27: The simplest way to answer this is if you can help us construct a program, whether as

Windows build broken

Hi devs, it seems the windows build is broken. (Can't build stage2 locally). Quickest way to reproduce is a validate of master. It also happens on CI: https://gitlab.haskell.org/ghc/ghc/-/jobs/270248 I remember ben mentioning something along the lines of builds with "old" (8.6) boot compilers

Request for two new MR-labels: "review-needed" and "changes-required"

Hello devs, Recently in a MR discussion the topic came up of contributors being frustrated about lack of reviews. As a contributor and as a reviewer the lack of tools to find MR's in need of attention also frustrated me often. I suggest two new MR labels: Label: "review-needed":  If a

Re: How to turn LHExpr GhcPs into CoreExpr

I tried this for fun a while ago and ran into the issue of needing to provide a type environment containing Prelude and so on. I gave up on that when some of the calls failed because I must have missed to set up some implicit state properly. I didn't have an actual use case (only curiosity) so I

Targeting old Windows versions

Hello devs, GHC is planning to use the Large Address Space mode of allocation for future releases on windows. See https://gitlab.haskell.org/ghc/ghc/issues/12576 This is a significant optimization for the GC and well tested as we use it on Linux already. However it will regress memory useage

Re: Module Renaming: GHC.Core.Op

egory but I concede it's not very good. But perhaps we should do the opposite as we're doing in GHC.Tc: put all the Core types in GHC.Core.Types and move everything operation from GHC.Core.Op to GHC.Core? Cheers, Sylvain On 03/04/2020 22:26, Andreas Klebinger wrote: Hello devs, While I

Re: Measuring compiler performance

Hi Simon, things I do to measure performance: * compile nofib/spectral/simple/Main.hs, look at instructions (perf) and allocations/time (+RTS -s) * compile nofib as a whole (Use NoFibRuns=0 to avoid running the benchmarks). Look at compile time/allocations. * compile Cabal the library (cd

Module Renaming: GHC.Core.Op

Hello devs, While I looked at the renaming a bit when proposed I only just realized we seem to be using Op as a short name for optimize. I find this very unintuitive. Can we spare another letter to make this GHC.Core.Opt instead? We use opt pretty much everywhere else in GHC already. Cheers

Re: [RFC] Compiler pipeline timings visualization

Hi Sergej, I think this is a good idea in general, and it seems you did some great work there already. Something like this can also help with pinpointing performance issues inside the compiler so would not just be useful to end users. intuitively I would assume that instead of adding another

Re: Removal of UniqMap module

My two cents: I needed it today and now I am unsure what the suitable replacement is. If you need it (inside GHC) just re add it. If you think it should be kept as part of GHC's API re add it and add a comment stating such. Iirc it was removed since no one used it, not because anything was

Re: profiling a constructor?

Surely, the RTS must be able to count the number of times a constructor is used. It can't. For one there are different kinds of "uses" for constructors. * Allocations - They might be dead by the time we gc the nursery, so the RTS never get's to see them. * Accessing the Constructor? That's even

Re: Fwd: Restricted sums in BoxedRep

From a implementors perspective my main questions would be: * How big is the benefit in practice? How many use cases are there? * How bad are the costs? (Runtime overhead, rts complexity, ...) The details of how this would be exposed to a user would are important. But if the costs are too high

Re: Fixing type synonyms to Uniq(D)FM newtypes

thread you refer to but it doesn't seem to explain why you went with solution 2. If you think it worthwhile can you explain here why you chose solution 2? On Tue, Jun 23, 2020 at 6:55 PM Andreas Klebinger mailto:klebinger.andr...@gmx.at>> wrote: There was a discussion about making UniqFM

Fixing type synonyms to Uniq(D)FM newtypes

There was a discussion about making UniqFM typed for the keys here a while ago. (https://mail.haskell.org/pipermail/ghc-devs/2020-January/018451.html and following) I wrote up an MR for one possible approach here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3577 It implements solution 2

Benchmarking experiences: Cabal test vs compiling nofib/spectral/simple/Main.hs

Hello Devs, When I started to work on GHC a few years back the Wiki recommended using nofib/spectral/simple/Main.hs as a test case for compiler performance changes. I've been using this ever since. "Recently" the cabal-test (compiling cabal-the-library) has become sort of a default benchmark

Re: On CI

After the idea of letting marge accept unexpected perf improvements and looking at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4759 which failed because of a single test, for a single build flavour crossing the improvement threshold where CI fails after rebasing I wondered. When would

Re: GHC 8.10 backports?

Yes, only changing the rule did indeed cause regressions. Whichwhen not including the string changes. I don't think it's worth having one without the other. But it seems you already backported this? See https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5263 Cheers Andreas Am 22/03/2021 um

Re: On CI

ebase, only 1 improves. That's news! But a blanket "accept improvements" won't tell you. I'm not hard against this proposal, because I know precise tracking has its own costs. Just wanted to bring up another scenario that might be factored in. Richard On Mar 24, 2021, at 7:44 AM, Andreas K

Re: On CI

> I'd be quite happy to accept a 25% regression on T9872c if it yielded a 1% improvement on compiling Cabal. T9872 is very very very strange! (Maybe if *all* the T9872 tests regressed, I'd be more worried.) While I fully agree with this. We should *always* want to know if a small syntetic

Re: Changes to performance testing?

This seems quite reasonable to me. Not sure about the cost of implementing it (and the feasability of it if/when merge-trains arrive). Andreas Am 21/02/2021 um 21:31 schrieb Richard Eisenberg: On Feb 21, 2021, at 11:24 AM, Ben Gamari mailto:b...@well-typed.com>> wrote: To mitigate this I

Re: Why can't arguments be levity polymorphic for inline functions?

Hey Clinton, I think the state of things is best summarised it's in principle possible to implement. But it's unclear how best to do so or even if it's worth having this feature at all. The biggest issue being code bloat. As you say a caller could create it's own version of the function with

Re: help validating a modified compiler?

I tried it myself and validate fails locally as well. I've created a ticket here: https://gitlab.haskell.org/ghc/ghc/-/issues/20506 Am 11/10/2021 um 22:27 schrieb Norman Ramsey: > Speaking for myself: I have not validated locally for quite a while. I just > rely on CI. I've confirmed that

Perf backtrace support.

Hello Devs, as some of you know I've recently been working on #8272. The goal being to use the machine stack register for the STG stack as a means to get perf backtraces. I've succeeded in making a branch that works for the first part but have so far been unable to get perf to generate proper

Re: [Take 2] Unexpected duplicate join points in "Core" output?

better. And having good examples for the problematic behaviour is always immensely helpful to solve these kinds of problems. Cheers Andreas Am 20/11/2021 um 19:54 schrieb Viktor Dukhovni: On Sat, Nov 20, 2021 at 12:49:08PM +0100, Andreas Klebinger wrote: For the assembly I opened a ticket

Re: DWARF support

Am 17/11/2021 um 17:08 schrieb Richard Eisenberg: For windows we have Portable Executable (PE) as the container format. This implies that the DWARF work is (unsurprisingly) completely inapplicable for Windows. It's not quite as simple. Dwarf info can be embedded into windows

Re: [Take 2] Unexpected duplicate join points in "Core" output?

Hello Victor, generally GHC does try to common up join points and duplicate expressions like that. But since that's relatively expensive most of the duplication happens during the core-cse pass which only happens once. We don't create them because they are harmless. They are simple a side

Re: 8-bit and 16-bit arithmetic

I think carter has it still right that it happens in the backends. If a new backend doesn't support these we could move this up into Cmm though without much issue I think. Am 28/10/2021 um 23:12 schrieb Carter Schonwald: I think thats done on a per backend basis (though theres been a lot of

Re: Alternatives for representing a reverse postorder numbering

Hello Norman, There is no invariant that Cmm control flow is reducible. So we can't always rely on this being the case. Depending on what you want to use this for this might or might not matter. In terms of implementation I think the question is if doing lookups in a LabelMap is more expensive

Re: Semantics of Cmm `switch` statement?

Hi Norman, I vaguely remember that we "finish" such unterminated code blocks by jumping to the block again. That is for code like this:     myswitch2 (bits32 n) {   foreign "C" D();     } We produce code like this:     {   cg: call "ccall" arg hints:  []  result hints:  [] D();   

Re: Absence info at run-time

W/W should transform such a function into one who takes one less argument removing any runtime overhead at least for fully applied functions. I suppose your suggestion is then if we an expression`f x` where bar takes multiple arguments, but doesn't use the current argument then GHC should: *

Re: How do you keep tabs on commits that fix issues?

Personally I try to include fixes #1234 in the commit so then I can just check which tags contain a commit mentioning the issue. If the issue isn't mentioned in the commit I usually look at the issue -> look for related mrs -> look for the commit with the fix -> grep for the commit message of

Re: [External] Re: Specialising NOINLINE functions

Am 09/05/2022 um 10:12 schrieb Simon Peyton Jones: I think the only downside is compilation time and code bloat. It can cause some rules to stop firing in a similar fashion as https://gitlab.haskell.org/ghc/ghc/-/issues/20364 discusses for W/W. But that can be fixed by adding the appropriate

Re: Mixed boxed/unboxed arrays?

. Cheers, Jaro On 02/08/2022 20:24, Andreas Klebinger wrote: I think it's possible to do this *today* using unsafeCoerce#. I was able to come up with this basic example below. In practice one would at the very least want to abstract away the gnarly stuff inside a library. But since it sounds like

Re: Mixed boxed/unboxed arrays?

I think it's possible to do this *today* using unsafeCoerce#. I was able to come up with this basic example below. In practice one would at the very least want to abstract away the gnarly stuff inside a library. But since it sounds like you want to be the one to write a library that shouldn't be

Re: Using GHC API with multiple targets

I think this is an ok forum for this kind of question. You could also try the haskell mailing list but I'm not sure if you will get more help tehre. I recently played around with the ghc api and I found the `hint` package to be quite helpful as an example on how to do various things when using

Re: Can't build nofib

Try adding --allow-newer we probably just haven't updated the bounds yet. (cd nofib; cabal v2-run --allow-newer -- nofib-run --compiler=`pwd`/../_build/stage1/bin/ghc --output=`date -I`) Am 12/07/2023 um 13:38 schrieb Simon Peyton Jones: Friends With a clean HEAD I can't build nofib.  See

Re: Can't build nofib

The nofib master branch has updated bounds. It's just ghcs submodule that's lagging behind. Am 12/07/2023 um 13:49 schrieb Rodrigo Mesquita: I would recommend —allow-newer rather than rebuilding with 9.4. In retrospect, 9.4 implies base == 4.17, but nofib seems to only allow < 4.17, which would

Re: Build GHC in GHC2021

On a whim tried enabling it by default but it failed first because GeneralizedNewtypeDeriving is incompatible with safe haskell and once I disabled GeneralizedNewtypeDeriving it failed with some error about missmatched kinds. I would welcome a patch doing this, but it's not a priority.