Re: simd branch ready for review

On 01/31/2013 08:40 PM, Bryan O'Sullivan wrote: On Thu, Jan 31, 2013 at 12:30 PM, Geoffrey Mainland mainl...@apeiron.net wrote: 2) SSE support is processor and platform dependent. What is the proper way for the programmer to know what SSE primitives are available? A CPP define? If so, what

Re: simd branch ready for review

On 02/04/2013 11:56 PM, Johan Tibell wrote: On Mon, Feb 4, 2013 at 3:19 PM, Geoffrey Mainland mainl...@apeiron.net wrote: What would a sensible fallback be for AVX instructions? What should we fall back on when the LLVM backend is not being used? Depends on the instruction. A 256-bit

Re: simd branch ready for review

On 02/06/2013 09:24 AM, Simon Marlow wrote: On 05/02/13 10:34, Geoffrey Mainland wrote: On 02/05/2013 09:06 AM, Simon Marlow wrote: On 05/02/13 00:36, Geoffrey Mainland wrote: On 02/04/2013 11:56 PM, Johan Tibell wrote: On Mon, Feb 4, 2013 at 3:19 PM, Geoffrey Mainland mainl...@apeiron.net

Re: Vector primops sizes

I haven't seen Michael's patches (where are they btw?), but there is some extra work to be done to ensure that 256-bit values are passed in registers. Otherwise adding support for wider vector types is fairly straightforward. The current plan is for 256-bit wide vector primops to always be

Re: Vector primops sizes

-support/ Alexander On Thu, Feb 14, 2013 at 12:29 AM, Geoffrey Mainland mainl...@apeiron.net mailto:mainl...@apeiron.net wrote: I haven't seen Michael's patches (where are they btw?), but there is some extra work to be done to ensure that 256-bit values are passed in registers

Re: [commit: ghc] simd: Fixup stack spills when generating AVX instructions. (b787b5d)

thought about how in an ideal world with lots of free time to hack on GHC we'd kill the mangler. Do we know that plan for this patch? If so it may be nice to document it somewhere and perhaps create a trac ticket. On 14 February 2013 23:16, Geoffrey Mainland gmain...@microsoft.com wrote

Advice needed: programmatically generating primops?

Hi All, There is a huge amount of boilerplate involved in adding a full complement of vector primops to GHC. I would like to reduce this boilerplate by programmatically generating the vector primops. My plan is to add utils/genvecprimops and #include its output into primops.txt.pp. Does this

Re: Advice needed: programmatically generating primops?

concatenation and stringification, it could be an option. Just a thought. On Fri, Feb 15, 2013 at 11:51 AM, Geoffrey Mainland mainl...@apeiron.net wrote: Hi All, There is a huge amount of boilerplate involved in adding a full complement of vector primops to GHC. I would like to reduce

Dreaded ... has stopped working with LLVM back end on Win64

I'm using the 7.6.2 Win64 port to try to compile HEAD with the quick-llvm BuildFlavour (I'm using LLVM 3.1). This entails setting -optlc-mtriple=x86_64-w64-mingw32 since the LLVM back-end doesn't output the right triple when producing .ll files. Unfortunately I get the dreaded ghc-cabal.exe has

Re: make install fails on Windows (8?) -- redux

On 02/22/2013 01:11 AM, Daniel Pratt wrote: My first attempt to build GHC (on Windows 8) from sources went pretty well until I got to the make install step. Some research revealed that at least one other person got the same error I did building on Windows. That other person fixed the problem

Re: SIMD/SSE support alignment

On 03/10/2013 09:52 PM, Nicolas Trangez wrote: All, I've been toying with the SSE code generation in GHC 7.7 and Geoffrey Mainland's work to integrate this into the 'vector' library in order to generate SIMD code from high-level Haskell code. While working with this, I wrote some simple

Re: SIMD/SSE support alignment

On 03/12/2013 03:01 PM, Johan Tibell wrote: On Tue, Mar 12, 2013 at 7:09 AM, Geoffrey Mainland mainl...@apeiron.net wrote: Unboxed vectors are allocated by GHC, and it does not align memory on 16-byte boundaries, so our first cut at SSE intrinsics simply used unaligned accesses. Obviously

Re: SIMD/SSE support alignment

On 03/12/2013 08:08 PM, Nicolas Trangez wrote: Hey, On Tue, 2013-03-12 at 14:09 +, Geoffrey Mainland wrote: On 03/10/2013 09:52 PM, Nicolas Trangez wrote: ... Hi Nicolas, Have you read our paper about the SIMD work? It's available here: https://research.microsoft.com/en-us/um/people

Re: LLVM 3.2 failure

On 03/14/2013 02:15 PM, Jan Stolarek wrote: Hm, you're sure that LLVM 3.2 is in your path when you configure GHC? I removed LLVM 3.0 from my system so there's no possibility of mistaking 3.2 with 3.0. I'm also getting lots of compilation warnings about untested LLVM version - this didn't happen

Re: LLVM 3.2 failure

Where are all the fingerprints for the libraries? You only seem to have the submodule libraries in there... Geoff On 03/14/2013 03:00 PM, Jan Stolarek wrote: I'm attaching a fingerprint - is this OK? I'm quite puzzled about this, mostly because yesterday I couldn't build GHC using LLVM 3.0

Re: LLVM 3.2 failure

I just tried building your fingerprinted tree here two different ways, and both failed: GHC 7.4.2 as bootstrap compiler + LLVM 3.2 GHC 7.6.2 as bootstrap compiler + LLVM 3.2 If you type llc -version at the command line, it really says it's 3.2? Geoff On 03/14/2013 03:06 PM, Jan Stolarek wrote:

Re: LLVM 3.2 failure

On 03/14/2013 04:40 PM, Jan Stolarek wrote: If you type llc -version at the command line, it really says it's 3.2? You don't seem to believe me :) Given that Austin and I have the stage 2 compiler failure and you don't, I think it is reasonable do double check :) [killy@xerxes : ~] llc

Re: LLVM 3.2 failure

for the 3.2 tarball here, but you'll of course have to apply manually and rebuild: https://github.com/thoughtpolice/homebrew/blob/35d39a504e619a3443abae0e249b366cc0ae4428/Library/Formula/llvm.rb#L108 On Thu, Mar 14, 2013 at 11:47 AM, Geoffrey Mainland mainl...@apeiron.net wrote: On 03/14/2013 04

Re: LLVM 3.2 failure

My stage 2 compiler was crashing the first time it was invoked. I just finished building GHC HEAD using LLVM compiled from HEAD, and that worked, so perhaps this was just a 3.2 bug. I have yet to run the testsuite though. Geoff On 03/14/2013 07:16 PM, Jan Stolarek wrote: Goeff, Austin, do

Re: LLVM 3.2 failure

source directory.) $ cd ghc $ make re2 GhcDebugged=YES And the new inplace/bin/ghc-stage2 compiler will have the debug runtime enabled. I don't have a lot of more time to dig at this exact moment. I'll look more tonight when I have time. On Thu, Mar 14, 2013 at 2:23 PM, Geoffrey Mainland

Re: Unreliability of the build system

I use separate build dirs because I synchronize my tree across multiple machines. It also makes it easy to blow away the build. Jan, you clearly have some stale build artifacts. Don't mix in-tree and out-of-tree builds. If you want to use out-of-tree builds, you can eliminate leftover build

New branch implementing typed/untyped Template Haskell

I have pushed a new branch, th-new, that partially implements the proposal outlined in Simon PJ's New directions for Template Haskell post at: http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal The main missing features are top-level pattern splices and local declaration

Re: New branch implementing typed/untyped Template Haskell

03369488) is registered in England and Wales Registered office 21 Station Road, Cambridge, CB1 2FB | -Original Message- | From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org] | On Behalf Of Geoffrey Mainland | Sent: 16 May 2013 16:22 | To: ghc-devs@haskell.org

Re: New branch implementing typed/untyped Template Haskell

week. Are there any special instructions regarding how to compile this branch? I will work on adding test cases, which would be translations of larger metaocaml programs. Jacques On 13-05-16 11:21 AM, Geoffrey Mainland wrote: I have pushed a new branch, th-new, that partially implements

Re: how to checkout proper submodules

I very much support moving to all-submodules. In fact, I argued for all-submodules when we made the half-submodules transition last year. Being able to easily check out a consistent and complete source code tree in a repeatable way is extremely important. Checking out by date works if you have

Re: how to checkout proper submodules

I don't know much about subtrees, but that might be another possibility? There are a lot of things to recommend moving to github. I do hate (non-empty) merge commits, though, so I'm not a fan of github's pull request mechanism. Geoff On 06/05/2013 09:43 AM, Manuel M T Chakravarty wrote: I

Re: how to checkout proper submodules

On 06/06/2013 09:44 PM, Simon Marlow wrote: On 05/06/13 16:59, Ian Lynagh wrote: On Tue, Jun 04, 2013 at 09:05:58PM -0500, Austin Seipp wrote: I know we had this discussion sometime recently I think, but can someone *please* explain why we are in this situation of half submodules, half

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

On 06/10/2013 11:49 AM, Nicolas Trangez wrote: On Mon, 2013-06-10 at 11:45 +0100, Ian Lynagh wrote: Side note: the fingerprint script *didn't even work* for almost a year after it was introduced; see commit 73ce2e70. Which implies that wanting to go back in time is rare, so making it easy

Linking to changeset on wiki

What is the magical incantation for linking to a changeset in a bug report/on the trac wiki? i can't for the life of me figure it out. Thanks, Geoff ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

On 06/12/2013 12:37 PM, Ian Lynagh wrote: On Wed, Jun 12, 2013 at 12:54:38AM +0200, Daniel Trstenjak wrote: I guess [the merge commits] may not cause any actual problems, but it's certainly nicer not having them (which is what using submodules gives us). Just to clarify, my problem isn't so

Re: Unreliability of the build system

I get the errors when running the testsuite too, but I excerpted the earliest recache warning from my full validation run. The same tests consistently fail for me. I only get the errors when running the testsuite with BINDIST=YES, as expected. Geoff On 06/24/2013 12:49 PM, Jan Stolarek wrote:

Re: Unreliability of the build system

On 06/24/2013 09:21 PM, Jan Stolarek wrote: My only claim was that I have a set of steps that can reliably reproduce an error on my system, not that these steps will reliably reproduce it on an arbitrary system, e.g., yours. Still, being able to reliably reproduce an error, even if only on one

Re: Unreliability of the build system

, Geoffrey Mainland napisał: On 06/24/2013 09:21 PM, Jan Stolarek wrote: My only claim was that I have a set of steps that can reliably reproduce an error on my system, not that these steps will reliably reproduce it on an arbitrary system, e.g., yours. Still, being able to reliably reproduce an error

Re: Unreliability of the build system

of the build, or files accessed by it, on NFS? Cheers, Simon On 24/06/13 23:44, Geoffrey Mainland wrote: On 06/24/2013 09:21 PM, Jan Stolarek wrote: My only claim was that I have a set of steps that can reliably reproduce an error on my system, not that these steps will reliably

Re: [commit: ghc] master: Major Llvm refactoring (a948fe8)

Hi David, The new LLVM patches appear to have broken the nightly perf-llvm builds. Last successful build report: http://www.haskell.org/pipermail/ghc-builds/2013-June/001297.html First failure build report: http://www.haskell.org/pipermail/ghc-builds/2013-June/001299.html I've inlined the

Re: adding avx register support to x86_32 as well as x86_64?

We would like code compiled with the LLVM back-end that doesn't use SIMD vectors to inter-operate with code compiled with the native codegen. The native codegen passes floating point arguments on the stack, so if we changed the GHC LLVM calling convention to pass Floats and Doubles in registers,

Re: Proposal: Gitolite for repository management

On 07/30/2013 10:41 AM, Austin Seipp wrote: Hello all, Recently with the new haskell.org server move, a few of us have taken roles of administrating the new server infrastructure including ghc.haskell.org, containing the GHC repositories. (Previously, the GHC repos were on

Re: GHC git server issue : warning: setlocale: LC_ALL: cannot change locale (en_AU.UTF-8)

On 08/05/2013 10:04 AM, Erik de Castro Lopo wrote: Hi all, I'm getting the above warning messahe every time I pull from the main GHC git repo. The strange thing is that this only happens on the GHC repo, on a whole bunch of others I get no such warning. After some pretty rigorous

Re: Machine-readable nightly output

The nightly builds are running on machines at MSR. They're behind a firewall/proxy, so even getting them to send out nightly emails was a chore. I was planning on turning off the nightlies before I leave since they frequently break (for example when libffi was moved into its own repo everything

Re: Disallow pushing of new trailing whitespace

Would be nice to have. How about a third hook that disallows commits that include whitespace-only changes unless *all* changes are whitespace-only? ;) Geoff On 08/20/2013 10:59 AM, Jan Stolarek wrote: Right now we have a git hook that prevents pushing a file containing tabs, unless that file

Re: Changes to primops break libraries (was Re: 7.8 Feature window)

This is not a completely serious suggestions, but... If we moved the magic GHC.Prim module to GHC.Prim.Base or something, then we could move GHC.PrimWrappers to GHC.Prim, have it import GHC.Prim.Base, and, assuming that we use Simon PJ's naming convention, (I think) no code would have to change.

Re: Alex and new Bool primops

Perhaps the core libraries committee should reconsider their decision? :) Backwards compatibility is good. If HEAD implements the backwards compatibility plan that Simon PJ and I suggested and said plan is working, there should be a compelling reason to break compatibility and have to go chasing

Re: Alex and new Bool primops

- Oryginalna wiadomość - Od: Geoffrey Mainland mainl...@apeiron.net Do: Jan Stolarek jan.stola...@p.lodz.pl DW: ghc-devs ghc-devs@haskell.org Wysłane: poniedziałek, 9 wrzesień 2013 15:40:09 Temat: Re: Alex and new Bool primops Perhaps the core libraries committee should reconsider their decision

Re: [core libraries] RE: Alex and new Bool primops

; Geoffrey Mainland; Jan Stolarek *Subject:* Re: [core libraries] RE: Alex and new Bool primops I'll admit a fair amount of ignorance of the GHC build process. But wouldn't it be standard that any tool used in the GHC build process itself, and built by GHC itself, would

Re: delete remote branch

Hi Herbert, On 09/08/2013 04:43 AM, Herbert Valerio Riedel wrote: Hello Nicolas, On 2013-09-08 at 09:41:04 +0200, Nicolas Frisby wrote: I just merged in my -fdicts-strict work, so I was deleting the old branch… but it's rejected for some reason. $ git push origin --delete dicts-strict

Re: llvm calling convention matters

On Wed, Sep 11, 2013 at 5:49 PM, Geoffrey Mainland mainl...@cs.drexel.edu mailto:mainl...@cs.drexel.edu wrote: Hi Carter, On 09/06/2013 03:24 PM, Carter Tazio Schonwald wrote: Hey Geoff, I'm leary about doing a calling convention change right before the ghc

Re: llvm calling convention matters

On 09/11/2013 07:33 PM, Johan Tibell wrote: On Wed, Sep 11, 2013 at 3:59 PM, Geoffrey Mainland mainl...@apeiron.net wrote: I don't see why we should limit ourselves by insisting that the gap between what the LLVM back-end and the native back-end not grow further. If we want SIMD

Re: llvm calling convention matters

compiling some code with -fllvm and some not in the same executable? On Wed, Sep 11, 2013 at 6:56 PM, Geoffrey Mainland mainl...@apeiron.net mailto:mainl...@apeiron.net wrote: We definitely have interop between the native codegen and the LLVM back end now. Otherwise anyone who

Re: delete remote branch

On 09/12/2013 05:06 AM, Jan Stolarek wrote: Not rebasing my branches is a terrible choice. The other options are to either never push my branches, or to push my branches somewhere other than to the main repo, e.g., github. One more choice is to create a new branch with -vX appended to the

Re: possible solution! Re: llvm calling convention matters

wish on anyone. pardon the verbose answer, but thats my offhand take cheers -Carter On Wed, Sep 11, 2013 at 10:10 PM, Geoffrey Mainland mainl...@apeiron.net mailto:mainl...@apeiron.net wrote: We support compiling some code with -fllvm

Re: possible solution! Re: llvm calling convention matters

. Geoff, it'd at least be worth running the benchmarks to measure the work! (and as I said, i'm happy to help) On Thu, Sep 12, 2013 at 2:30 PM, Geoffrey Mainland mainl...@apeiron.net mailto:mainl...@apeiron.net wrote: If users have to do

Re: HEADS UP: New primops on the way

On 09/16/2013 09:48 AM, Jan Stolarek wrote: There will be a major change in primops pushed into HEAD, hopefully with next 24 hours. This change breaks backwards compatibility for comparison primops and ONCE IT IS PUSHED will require you to: 1) Upgrade to latest versions of Alex and Happy

Re: llvm calling convention matters

remember what the outcome was. Cheers, Simon On 12/09/13 03:10, Geoffrey Mainland wrote: We support compiling some code with -fllvm and some not in the same executable. Otherwise how could users of the Haskell Platform link their -fllvm-compiled code with native-codegen-compiled

Re: llvm calling convention matters

, was there a particular difficulty you had implementing these primops? On Wed, Sep 18, 2013 at 4:22 PM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com wrote: On 18/09/13 20:01, Geoffrey Mainland wrote: We did discuss this, but you may not have been present. If LLVM-only

Re: llvm calling convention matters

such a way. I hope that answers your question. that seems to be a deep enough issue that theres no way to resolve it with simple engineering in the next few weeks. -Carter On Wed, Sep 18, 2013 at 9:41 PM, Geoffrey Mainland mainl...@apeiron.net mailto:mainl

Re: I've moved the primitive package to github

On 9/24/13 6:17 PM, Herbert Valerio Riedel wrote: Hello Jan, On 2013-09-24 at 20:47:31 +0200, Jan Stolarek wrote: Your patches are based on an outdated version of the library. That's really surprising - I based them on code available at http://code.haskell.org/primitive, which I believe

Re: I've moved the primitive package to github

On 09/25/2013 02:51 AM, Herbert Valerio Riedel wrote: On 2013-09-25 at 02:40:51 +0200, Geoffrey Mainland wrote: [...] However, I've tried integrating the new vector/primitive versions released into the GHC build (after patching up the DPH libs), but I get Core lint errors: http

Out with the new, in with the old for the vector library WAS: [commit: packages/vector] ghc-head: Snapshot of the real 0.10.0.1 release (a3a65b5)

Hi Bryan, I apologize for not bringing this issue up in a more timely fashion. I'm curious why the Bundle support that Roman added to the vector library was removed. I understand that the change in representation made it difficult for, e.g., dph to use the new vector library, but this change in

Re: Repository Reorganization Question

I'm all for converting to submodules. Since we will have submodules anyway, we could also convert testsuite et al to submodules and see how painful that is before deciding to fold them in to the main repo. I'm not clear on the pros/cons of having, e.g., testsuite, as a submodule vs folded in. The

Re: HEADS-UP: Git submodule conversion imminent

Thank you Geoff On 6/25/14, 4:46 AM, Herbert Valerio Riedel wrote: It's done! After pulling the latest ghc.git commit (and assuming you have made sure you have no unpushed data laying around in the repos listed below) you'll have to either run - git submodule update --init *or*

Re: I'm going to disable DPH until someone starts maintaining it

I have patches for DPH that let it work with vector 0.11 as of a few months ago. I would be happy to submit them via phabricator if that is agreeable (we have to coordinate with the import of vector 0.11 though...I can instead leave them in a wip branch for Austin to merge as he sees fit). I am

Re: I'm going to disable DPH until someone starts maintaining it

x64. Is there an easy way for me to validate on other platforms? Thanks, Geoff On 08/04/2014 10:07 AM, Austin Seipp wrote: On Mon, Aug 4, 2014 at 8:49 AM, Geoffrey Mainland mainl...@apeiron.net wrote: I have patches for DPH that let it work with vector 0.11 as of a few months ago. I would

Re: I'm going to disable DPH until someone starts maintaining it

Hi Austin, I haven't heard back from you about this, and D302 has been waiting for review in phab for two weeks. This seems to be a minor change, so if I don't hear otherwise by the end of the week, I'm going to go ahead and merge. Thanks, Geoff On 08/29/2014 01:29 PM, Geoffrey Mainland wrote

Re: vectorisation code?

these circumstances, I would also very much prefer for Geoff | getting the code in order and leaving it in GHC. | | Manuel | | Geoffrey Mainland mainl...@apeiron.net: | | I'm sorry I'm a bit late to the game here, but there is also the | option of reconnecting DPH to the build

Re: vectorisation code?

I'm sorry I'm a bit late to the game here, but there is also the option of reconnecting DPH to the build. When I patched DPH for the new version of the vector library, I did not perform this step---now I'm sorry I didn't. I am willing to get DPH in working order again---I believe the required

Re: vectorisation code?

On 01/22/2015 10:50 AM, Herbert Valerio Riedel wrote: On 2015-01-22 at 14:59:51 +0100, Geoffrey Mainland wrote: The current situation is that DPH is not being built or maintained at all. Given this state of affairs, it is hard to justify keeping it around---DPH is just bitrotting. I am

Re: Pre-Proposal: Introspective Template Haskell

ompatibility > shim would likely be called template-haskell. (I retract the idea of > deprecating the package. But we could democratize its maintenance rather > easily after this change.) > > Richard > > On Nov 12, 2015, at 12:12 PM, Geoffrey Mainland <mainl...@apeiron.ne

Re: Pre-Proposal: Introspective Template Haskell

Hi Richard, Please correct me if I misunderstand, but in summary, you propose to change Template Haskell so that GHC's internal AST is produced directly, instead of the current route where there is an intermediate TH AST? Geoff On 11/11/2015 11:26 AM, Richard Eisenberg wrote: > Hi devs, > >

Re: Do we need to maintain PrimRep.VecRep?

VecRep is used for vector operations. If you aren't using LLVM, you won't see them. VecRep's are generated by utils/genprimopcode/Main.hs. Check out compiler/stage1/build/primop-vector-tys.hs-incl in your build tree---should be plenty of generated VecRep's there :) Cheers, Geoff On 06/07/2016

Re: Do we need to maintain PrimRep.VecRep?

wrote: > Thanks, I can see the TyCons with VecReps there.. but I still can't see how > the > terms are constructed? Can you show me some example programs, or functions in > the compiler, that generate vector terms? (e.g. terms with types with VecReps) > > 2016-06-07 10:48 GMT-04:00

Best practices for merging?

I've been away from GHC for a while, and it's not clear to me what the best practices for merging are now. My usual git workflow is to work on a feature branch, get a nice clean set of patches, each of which implements a discrete bit of functionality, rebase onto master, and then merge with an

Re: Best practices for merging?

On 01/31/2016 02:47 PM, Tuncer Ayaz wrote: > On 31 January 2016 at 19:24, Joachim Breitner wrote: >> Hi, >> >> Am Sonntag, den 31.01.2016, 13:10 -0500 schrieb Geoffrey Mainland: >>> My usual git workflow is to work on a feature branch, get a nice >>> clean s

Build broken

I attempted to rebase my fix for #11487, but I can no longer validate. The culprit is 6c7760b2. I am seeing the errors below under linux, building with 7.10.3. Herbert, I hope there is a quick fix? Thanks, Geoff libraries/unix/System/Posix/IO/Common.hsc:316:61: error: • Couldn't match type

Re: PrimRep constructor Vec

rom primops.txt > > Simon > > | -Original Message- > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of > | Richard Eisenberg > | Sent: 02 February 2016 21:34 > | To: Geoffrey Mainland <mainl...@drexel.edu> > | Cc: ghc-devs@haskell.

Re: Best practices for merging?

On 02/01/2016 09:44 AM, Jan Stolarek wrote: >> If there are multiple commits then a merge commit can serve to logically >> group them. > The cost of this is non-linear history. But I am still not sure what the > actual benefit is? If the > commits come one after another they are still logically

Re: vectorisation code?

On 1/22/16 8:05 AM, Ben Gamari wrote: > Manuel M T Chakravarty writes: > >> The way I see it, > the main cost of keeping DPH around is to handle >> breakages such as that with vector. I can’t promise to address those >> in a timely manner, which is why I agreed to

Re: vectorisation code?

On 1/22/16 11:36 AM, Herbert Valerio Riedel wrote: > On 2016-01-22 at 17:23:18 +0100, Geoffrey Mainland wrote: >> I didn't mean to suggest that DPH should be part of every build, just >> that it should be part of *some* regular build. >> >> If we're willing to do that,

Re: vectorisation code?

On Fri, Jan 22, 2016 at 03:23:56PM +0100, Thomas Miedema wrote: > On Fri, Jan 22, 2016 at 3:17 PM, Geoffrey Mainland <mainl...@apeiron.net> > wrote: >> On 1/22/16 8:05 AM, Ben Gamari wrote: >>> Manuel M T Chakravarty <c...@cse.unsw.edu.au> writes: >>>&g

Re: GHC 8.0.1-rc3 source tarball availability

Does it take a while for the source tarball to show up? All I see is the Linux binary distribution. Geoff On 04/10/2016 11:05 AM, Ben Gamari wrote: > tl;dr: If you would like to produce a binary distribution for GHC >8.0.1-rc3 then let us know, grab the source distribution and >

Re: Reification of out-of-scope variables?

I'm afraid I'm coming late to the game, so I'm not clear on the extent of the problem (or even precisely what it is that isn't working). In addition to creating a ticket, it would be great to have a wiki page that outlines the problem and proposed solution(s). The TH finalizer stuff was meant to

Re: LLVM calling convention for AVX2 and AVX512 registers

On 03/14/2017 04:02 PM, Ben Gamari wrote: > Edward Kmett writes: > >> Hrmm. In C/C++ I can tell individual functions to turn on additional ISA >> feature sets with compiler-specific __attribute__((target("avx2"))) tricks. >> This avoids complains from the compiler when I call

Re: LLVM calling convention for AVX2 and AVX512 registers

We would need to get a patch to LLVM accepted to change the GHC calling convention. Now that we commit to a particular version of LLVM, this might be less of an issue than it once was since we wouldn't have to support versions of LLVM that didn't support the new calling convention. So...how do