Re: Coercible questions

k. > > Sandy > > On Sat, Oct 5, 2019 at 4:17 PM Michal Terepeta > wrote: > >> Hi, >> >> I've started looking into using `Data.Coerce` (and the `Coercible` >> type-class) for a personal project and was wondering why coercing between >> `Int` and `

Coercible questions

Hi, I've started looking into using `Data.Coerce` (and the `Coercible` type-class) for a personal project and was wondering why coercing between `Int` and `Word` is not allowed? I don't see any fundamental reason why this shouldn't work... Perhaps, it's just a matter of GHC's implementation

Re: [GHC DevOps Group] The future of Phabricator

Hope you don't mind if I add an opinion of a small/occasional contributor to the thread. Personally, I would prefer a move to GitHub. Mostly due to familiarity and network effect (pretty much everyone is on GitHub). But I would also consider a move to GitLab a big improvement over the current

Re: understanding assertions, part deux :) Re: whither built in unlifted Word32# / Word64# etc?

I've rebased the diff and relaxed the assertion - do take a look if that looks reasonable to you :) https://phabricator.haskell.org/D4475 Cheers! - Michal On Wed, Jul 25, 2018 at 9:03 PM Michal Terepeta wrote: > Hi Carter, > > I didn't write this assertion. I only validated loca

Re: understanding assertions, part deux :) Re: whither built in unlifted Word32# / Word64# etc?

CodeGen.hs#L2764 >> >> Upon commenting that assert the tests run fine. Am I missing something or >> is the failure expected? >> >> Thanks, >> Abhiroop >> >> On Mon, Jul 9, 2018 at 8:31 PM Michal Terepeta >> wrote: >> >>

Re: ZuriHac 2018 GHC DevOps track - Request for Contributions

be fair amount of improvisation... Are you coming to this week's HaskellerZ meetup? We could chat a bit more about this. Cheers! - Michal On Tue, May 22, 2018 at 12:07 PM Niklas Hambüchen wrote: > On 08/04/2018 15.01, Michal Terepeta wrote: > > I'd be happy to help. :) I know a

Re: Question about ArrayArray#

On Thu, May 3, 2018 at 2:40 PM Carter Schonwald wrote: > I think Ed’s structs package explicitly makes use of this :) > Oh, interesting! Thanks for the pointer! Looking at Ed's code, he's seems to be doing something similar to that I'm also interested in: having a

Question about ArrayArray#

Hi all, I have a quick question about ArrayArray#. Is it safe to store *both* an ByteArray# and ArrayArray# within the *same* ArrayArray#? For instance: - at index 0 of an ArrayArray# I store a different ArrayArray#, - at index 1 of that same ArrayArray# I store a ByteArray#. It seems to me that

Re: ZuriHac 2018 GHC DevOps track - Request for Contributions

On Sat, Apr 7, 2018 at 3:34 PM Niklas Hambüchen wrote: > Hi GHC devs, > > The ZuriHac 2018 conference will feature a GHC DevOps track (which > Andreas and I are coordinating), that will be all about fostering > contributions to GHC and learning to hack it. There will be a room or >

Re: New slow validate errors

Yes, sorry for that! This is tracked in: https://ghc.haskell.org/trac/ghc/ticket/14989 Revert: https://phabricator.haskell.org/D4577 - Michal On Sun, Apr 8, 2018 at 11:08 AM Ömer Sinan Ağacan wrote: > Hi, > > I see a lot of these errors in slow validate using current GHC

Re: Is "cml_cont" of CmmCall used in practice?

On Sun, Mar 18, 2018 at 6:38 AM Shao, Cheng wrote: > Hi all, > > Is the "cml_cont" field of the CmmCall variant is really used in practice? > I traversed the output of raw Cmm produced by ghc compiling the whole base > package, but the value of cml_cont is always Nothing. >

Re: [commit: ghc] master: Hoopl.Collections: change right folds to strict left folds (2974b2b)

On Mon, Feb 5, 2018 at 12:19 PM Simon Peyton Jones wrote: > Hi Michael > > Thanks for pushing forward with Hoopl and other back-end things. > > Did this patch elicit any performance gains? Or what brought it to your > attention? > I noticed this some time ago and just

Re: New primitive types?

On Sun, Aug 27, 2017 at 7:49 PM Michal Terepeta <michal.terep...@gmail.com> wrote: > > On Thu, Aug 3, 2017 at 2:28 AM Sylvain Henry <sylv...@haskus.fr> wrote: > > Hi, > > > > I also think we should do this but it has a lot of ramifications: > co

Re: New primitive types?

> On Thu, Aug 3, 2017 at 2:28 AM Sylvain Henry wrote: > Hi, > > I also think we should do this but it has a lot of ramifications: contant folding in Core, codegen, TH, etc. > > Also it will break codes that use primitive types directly, so maybe it's worth a ghc proposal. Ok,

Re: GHC release timing and future build infrastructure

On Tue, Aug 1, 2017 at 4:19 AM Ben Gamari wrote: > > Hello everyone, > > I just posted a pair of posts on the GHC blog [1,2] laying out some > thoughts on the GHC release cycle timing [1] and how this relates to the > in-progress Jenkins build infrastructure [2]. When you

Re: New primitive types?

On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald wrote: > One issue with packed fields is that on many architectures you can't quite do subword reads or > writes. So it might not always be a win. Could you give any examples? Note that we're still going to do aligned

New primitive types?

Hi all, I'm working on making it possible to pack constructor fields [1], example: ``` data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Int32 ``` should only require 4 bytes for unpacked `Float` and 4 bytes for unpacked `Int32`, which on 64-bit arch would take just 1 word (instead of 2 it

Re: WordX/IntX wrap Word#/Int#?

Just for the record, I've opened: https://ghc.haskell.org/trac/ghc/ticket/13825 to track this. Cheers, Michal On Mon, Jun 12, 2017 at 8:45 PM Michal Terepeta <michal.terep...@gmail.com> wrote: > Thanks a lot for the replies & links! > > I'll try to finish Simon's diff (and

Re: WordX/IntX wrap Word#/Int#?

Thanks a lot for the replies & links! I'll try to finish Simon's diff (and probably ask silly questions if I get stuck ;) Cheers, Michal ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Removing Hoopl dependency?

> On Mon, Jun 12, 2017 at 8:05 PM Ben Gamari wrote: > Simon Peyton Jones via ghc-devs writes: > > Snip > > > > That would leave Sophie free to do (B) free of the constraints of GHC > > depending on it; but we could always use it later. > > > > Does

WordX/IntX wrap Word#/Int#?

Hi all, I've just noticed that all `WordX` (and `IntX`) data types are actually implemented as wrappers around `Word#` (and `Int#`). This probably doesn't matter much if it's stored on the heap (due to pointer indirection and heap alignment), but it also means that: ``` data Foo = Foo {-# UNPACK

Re: Removing Hoopl dependency?

> On Fri, Jun 9, 2017 at 9:50 AM Simon Peyton Jones wrote: > > Maybe this is the core of our disagreement - why is it a good idea to have Hoopl as a separate package in the first place? > > > One reason only: because it makes Hoopl usable by compilers other than GHC. And,

Re: Removing Hoopl dependency?

> On Wed, Jun 7, 2017 at 7:05 PM Simon Peyton Jones wrote: > Michael > > Sorry to be slow. > > > Note that what I’m actually advocating is to *finish* forking Hoopl. The > > fork really started in ~2012 when the “new Cmm backend” was being > > finished. > > Yes, I know.

Re: Removing Hoopl dependency?

Cool, thanks for quick replies! I've sent out https://phabricator.haskell.org/D3616 Cheers, Michal ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: FYI: removing `fibon`

ode with something > used as part of normal nofib test cases. > > 2017-03-14 19:59 GMT+01:00 Michal Terepeta <michal.terep...@gmail.com>: > > Hi all, > > I wanted to remove `fibon` (from `nofib`) - it's broken, abandoned > upstream (no commits in 5 years) a

Re: Stat too good

Just FYI: I'm on 64-bit Linux and don't see those failures (I just validated at 763f43e6d3) Cheers, Michal On Fri, Mar 17, 2017 at 6:49 PM Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > Ben, > > I still get these four stat-too-good “failures” on 64-bit Linux. > > Unexpected

FYI: removing `fibon`

Hi all, I wanted to remove `fibon` (from `nofib`) - it's broken, abandoned upstream (no commits in 5 years) and I'm not aware of anyone using it or working on it. At this point I don't think it makes sense to try to revive it - I'd prefer putting the time/effort into getting a few new benchmarks.

Re: nofib on Shake

On Tue, Jan 10, 2017 at 11:35 AM Gracjan Polak wrote: > I was looking nearby recently and you might want to take into account my > discoveries described in https://ghc.haskell.org/trac/ghc/ticket/11501 Thanks a lot for mentioning it! (I didn't see this ticket/discussion)

Re: nofib on Shake

On Sun, Jan 8, 2017 at 10:56 PM Joachim Breitner wrote: > Hi, > > Am Sonntag, den 08.01.2017, 13:45 -0500 schrieb Ben Gamari: > > > We could also create a cabal and stack files for `nofib-analyse` (making > > > it possible to use some libraries for it). > > > > > This

Re: nofib on Shake

> On Sun, Jan 8, 2017 at 7:45 PM Ben Gamari <b...@well-typed.com> wrote: > Michal Terepeta <michal.terep...@gmail.com> writes: > > > Hi all, > > > > While looking at nofib, I've found a blog post from Neil Mitchell [1], > > which describes a Shake b

nofib on Shake

Hi all, While looking at nofib, I've found a blog post from Neil Mitchell [1], which describes a Shake build system for nofib. The comments mentioned that this should get merged, but it seems that nothing actually happened? Is there some fundamental reason for that? If not, I'd be interested

Re: Measuring performance of GHC

On Tue, Dec 6, 2016 at 10:10 PM Ben Gamari wrote: > [...] > > How should we proceed? Should I open a new ticket focused on this? > > (maybe we could try to figure out all the details there?) > > > That sounds good to me. Cool, opened:

Re: Measuring performance of GHC

> On Tue, Dec 6, 2016 at 2:44 AM Ben Gamari <b...@smart-cactus.org> wrote: > Michal Terepeta <michal.terep...@gmail.com> writes: > > [...] >> >> Looking at the comments on the proposal from Moritz, most people would >> prefer to >> extend/improve

Re: Measuring performance of GHC

On Mon, Dec 5, 2016 at 12:00 PM Moritz Angermann wrote: > Hi, > > I’ve started the GHC Performance Regression Collection Proposal[1] > (Rendered [2]) > a while ago with the idea of having a trivially community curated set of > small[3] > real-world examples with

Measuring performance of GHC

Hi everyone, I've been running nofib a few times recently to see the effect of some changes on compile time (not the runtime of the compiled program). And I've started wondering how representative nofib is when it comes to measuring compile time and compiler allocations? It seems that most of the

Re: Status of "Improved LLVM backend"

On Mon, Nov 28, 2016 at 2:43 AM Moritz Angermann wrote: [...] > For the llvm code gen in ghc it’s usually the `_fast` suffix functions. See [1] and > the `genStore_fast` 30 lines further down. My bitcode llvm gen follows that file [1], > almost identically, as can be seen

Re: Status of "Improved LLVM backend"

> Hi, > > I’m trying to implement a bitcode producing llvm backend[1], which would potentially > allow to use a range of llvm versions with ghc. However, this is only tangentially > relevant to the improved llvm backend, as Austin correctly pointed out[2], as there are > other complications

Status of "Improved LLVM backend"

Hi all, I was wondering what’s the current status of the “Improved LLVM backend” project ( https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend ). The page mentions a few main problems, but some seem to be already fixed: 1) Using/supporting only one version of LLVM. This has been done

Re: Dataflow analysis for Cmm

On Fri, Oct 21, 2016 at 4:04 PM Simon Marlow <marlo...@gmail.com> wrote: > On 16 October 2016 at 14:03, Michal Terepeta <michal.terep...@gmail.com> > wrote: > > Hi, > > I was looking at cleaning up a bit the situation with dataflow analysis > for Cmm. >

Re: Dataflow analysis for Cmm

On Mon, Oct 17, 2016 at 10:57 AM Jan Stolarek wrote: > Michał, > > Dataflow module could indeed use cleanup. I have made two attempts at this > in the past but I don't > think any of them was merged - see [1] and [2]. [2] was mostly > type-directed simplifications. It >

Dataflow analysis for Cmm

Hi, I was looking at cleaning up a bit the situation with dataflow analysis for Cmm. In particular, I was experimenting with rewriting the current `cmm.Hoopl.Dataflow` module: - To only include the functionality to do analysis (since GHC doesn’t seem to use the rewriting part). Benefits: -

Re: Hoopl question

On Sun, May 3, 2015 at 7:39 PM Jan Stolarek jan.stola...@p.lodz.pl wrote: Michał, one of my students is currently working on this: https://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup as his BSc thesis (see #8315). It might turn out that he will also have enough time to focus on

Hoopl question

Hi, I've just read through the Hoopl paper and then noticed https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance which is really interesting. But it seems that there were no updates to the page in like 3 years, yet the new codegen seems to be using Hoopl... Does anyone know