Re: help wrt semantics / primops for pure prefetches
I haven't been watching this, but I have one question: does prefetching actually *work*? Do you have benchmarks (or better still, actual library/application code) that show some improvement? I admit to being slightly sceptical - when I've tried using prefetching in the GC it has always been a struggle to get something that shows an improvement, and even when I get things tuned on one machine it typically makes things slower on a different processor. And that's in the GC, doing it at the Haskell level should be even harder. Cheers, Simon On 22/11/2014 05:43, Carter Schonwald wrote: Hey Everyone, in https://ghc.haskell.org/trac/ghc/ticket/9353 and https://phabricator.haskell.org/D350 is some preliminary work to fix up how the pure versions of the prefetch primops work is laid out and prototyped. However, while it nominally fixes up some of the problems with how the current pure prefetch apis are fundamentally borken, the simple design in D350 isn't quite ideal, and i sketch out some other ideas in the associated ticket #9353 I'd like to make sure pure prefetch in 7.10 is slightly less broken than in 7.8, but either way, its pretty clear that working out the right fixed up design wont happen till 7.12. Ie, whatever makes 7.10, there WILL have to be breaking changes to fix those primops for 7.12 thanks and any feedback / thoughts appreciated -Carter ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Keeping the Newcomers wiki page alive
On 13/11/2014 07:43, Jan Stolarek wrote: I believe that current difficulty field is intended to mean the amount of time required by someone who already knows what to do. Obviously, that's not the metric that we want to use for labelling newcomer-friendly tasks. (I wonder if the difficulty field in its current form is even useful to us?) Obviously, the metric that we want is the amount of code familiarity required to fix a bug. For newcommers we probably want tickets that require knowledge of 1000 lines of code. I think the important questions are: 1. Do we find the current difficulty field useful? 2. Should we have a Trac field to label accessibility for newcomers? My answers are: 1. No. We could remove the Difficulty field, given that it hasn't really been useful and it can be subsumed by the keywords field for the things we want it for. It was originally intended to help (a) new developers find tickets to work on, and (b) help us find good projects for the GSoc. Both of which can be keywords, so I'd be happy to get rid of Difficulty. Cheers, Simon 2. Yes, we should have a filed with accessibility levels like: newcomer/intermediate/advanced/rocket science. If we have 2) then we can have a list of tickets in the Newcomers page generated dynamically. Janek Dnia czwartek, 13 listopada 2014, Richard Eisenberg napisał: Forgive me if I'm repeating others' comments, but the newcomer label, to me, is independent of level of difficulty -- it has much more to do with how messy the work is, I think. I'll make a concrete proposal: Tag appropriate bugs/feature requests with newcomer and, if you want, mention that you'll mentor in a comment. I don't think there's a glaring need to be able to search by mentor, so I'm not proposing a Trac field for that. If I see here that a few others will adopt this proposal, I'll start doing it -- I already have several tickets in mind. Richard On Nov 12, 2014, at 6:27 PM, Isaac Hollander McCreery ihmccre...@gmail.com wrote: Glad people are excited about this, I like beginner/intermediate/advanced. I think it's more accurate than easy/hard and clearer than accessible, welcoming, etc. I also want to call out the mentor label that the Rust team is using: experienced devs nominate themselves as mentors on projects, then newcomers can tackle them with some support. As a newcomer, that's *extremely* appealing to me. Cheers, Ike On Wed, Nov 12, 2014 at 2:34 PM, Brandon Allbery allber...@gmail.com wrote: On Wed, Nov 12, 2014 at 5:32 PM, Joachim Breitner m...@joachim-breitner.de wrote: The quality that we are looking for is “tacklabe by a newcomer“, i.e. not requiring too deep knowledge of GHC. Is there a nice word for that? I found “accessible”, “welcoming”, “appealing” – anything that sounds good in native English speaker’s ears? :-) Various projects I'm involved with use difficulty: beginner (or just beginner) babydev-bait (!) newcomer (several use newbie but I do not recommend that label) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: help wrt semantics / primops for pure prefetches
My general experience with prefetching is that it is almost never a win when done just on trees, as in the usual mark-sweep or copy-collection garbage collector walk. Why? Because the time from the time you prefetch to the time you use the data is too variable. Stack disciplines and prefetch don't mix nicely. If you want to see a win out of it you have to free up some of the ordering of your walk, and tweak your whole application to support it. e.g. if you want to use prefetching in garbage collection, the way to do it is to switch from a strict stack discipline to using a small fixed-sized queue on the output of the stack, then feed prefetch on the way into the queue rather than as you walk the stack. That paid out for me as a 10-15% speedup last time I used it after factoring in the overhead of the extra queue. Not too bad for a weekend project. =) Without that sort of known lead-in time, it works out that prefetching is usually a net loss or vanishes into the noise. As for the array ops, davean has a couple of cases w/ those for which the prefetching operations are a 20-25% speedup, which is what motivated Carter to start playing around with these again. I don't know off hand how easily those can be turned into public test cases though. -Edward On Thu, Nov 27, 2014 at 4:36 AM, Simon Marlow marlo...@gmail.com wrote: I haven't been watching this, but I have one question: does prefetching actually *work*? Do you have benchmarks (or better still, actual library/application code) that show some improvement? I admit to being slightly sceptical - when I've tried using prefetching in the GC it has always been a struggle to get something that shows an improvement, and even when I get things tuned on one machine it typically makes things slower on a different processor. And that's in the GC, doing it at the Haskell level should be even harder. Cheers, Simon On 22/11/2014 05:43, Carter Schonwald wrote: Hey Everyone, in https://ghc.haskell.org/trac/ghc/ticket/9353 and https://phabricator.haskell.org/D350 is some preliminary work to fix up how the pure versions of the prefetch primops work is laid out and prototyped. However, while it nominally fixes up some of the problems with how the current pure prefetch apis are fundamentally borken, the simple design in D350 isn't quite ideal, and i sketch out some other ideas in the associated ticket #9353 I'd like to make sure pure prefetch in 7.10 is slightly less broken than in 7.8, but either way, its pretty clear that working out the right fixed up design wont happen till 7.12. Ie, whatever makes 7.10, there WILL have to be breaking changes to fix those primops for 7.12 thanks and any feedback / thoughts appreciated -Carter ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: let app invariant failure, HALP Re: how to write a ghc primop that acts on an unevaluated argument?
are you quite sure you did –dverbose-core2core –ddump-occur-anal? I see none
of that output in the file.
Regardless of the flags you set for the primop, I’m surprised that the
invariant is invalidated. Should not happen.
As well as the revised output, could you enclose a snippet of primops.txt.pp
for prefetchValue1,2,3#
S
From: Carter Schonwald [mailto:carter.schonw...@gmail.com]
Sent: 25 November 2014 06:47
To: Simon Peyton Jones
Cc: Edward Kmett; ghc-devs@haskell.org; Joachim Breitner
Subject: Re: let app invariant failure, HALP Re: how to write a ghc primop that
acts on an unevaluated argument?
ok attached is the log of
./inplace/bin/ghc-stage2 codetester.hs -O2 -dcore-lint -fforce-recomp
-ddump-simpl -ddump-to-file -dverbose-core2core -ddump-occur-anal
-ddump-inlinings output ^1
the relevant snippet is bellow.
It looks like the Float-Out transformation is what tripping it.
That said, reading through what the semantics are implied by has_side_effects =
True, the prefetch* family of operations ARE side effectful with respect the
fact that they DO modify the CPU cache in a way that changes what memory
locations are in various levels of CPU cache, so despite seeming read-like,
they are modifying the state of the system, just in a way that is ONLY visible
wrt the performance characteristics/runtime of the resulting program.
specifically, Duplication, Floating out, and Specultive evaluation all change
*when* the prefetch runs and changes the CPU state, and Discard means this
mutation of the CPU cache state would not happen.
if prefetch was pure semantically (ie equiv to a - () ) , they'd just be no
op, they're exclusively a tool for performance engineering, and accordingly
when and where they appear in code matters!
i'm more than happy to write out a more detailed version of this explanation
somewhere if you like.
-Carter
*** Core Linted result of Simplifier:
*** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}):
*** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True,
OverSatApps = True}):
*** Core Lint errors : in result of Float out(FOS {Lam = Just 0,
Consts = True,
OverSatApps = True}) ***
no location info: Warning:
In the expression: prefetchValue2#
@ [Char]
@ RealWorld
lvl_s3Oi
(prefetchValue1#
@ Int
@ RealWorld
lvl_s3Oj
(prefetchAddr3# @ RealWorld ds1_a3zg 0 ds_a3zf))
This argument does not satisfy the let/app invariant:
prefetchValue1#
@ Int
@ RealWorld
lvl_s3Oj
On Mon, Nov 24, 2014 at 10:43 PM, Carter Schonwald
carter.schonw...@gmail.commailto:carter.schonw...@gmail.com wrote:
huh, apparently i was mixing up '-' and some other similar dash character, time
to let my rebuild of ghc go through then try gain :)
On Mon, Nov 24, 2014 at 10:37 PM, Carter Schonwald
carter.schonw...@gmail.commailto:carter.schonw...@gmail.com wrote:
when i run
./inplace/bin/ghc-stage2 codetester.hs -O2 -dcore-lint -S -fforce-recomp
-ddump-simpl -ddump-to-file –dverbose-core2core –ddump-occur-anal
–ddump-inlinings
i get
target ‘–dverbose-core2core’ is not a module name or a source file
what am I doing wrong in this CLI invocation?
On Mon, Nov 24, 2014 at 10:23 AM, Simon Peyton Jones
simo...@microsoft.commailto:simo...@microsoft.com wrote:
Carter
That smells wrong to me. These flags have a very carefully defined meaning; see
Note [PrimOp can_fail and has_side_effects]
in PrimOp.lhs
If you say it has side effects when it doesn’t, you’ll confuse your successor
reading the code in five years time.
Better to find out what is going on and why. Might you do that? What
transformation invalidates the let/app invariant? Make a small test case, use
–dverbose-core2core –ddump-occur-anal –ddump-inlinings. I would far rather
that than install a land-mine in the code.
Simon
From: Carter Schonwald
[mailto:carter.schonw...@gmail.commailto:carter.schonw...@gmail.com]
Sent: 24 November 2014 00:54
To: Edward Kmett
Cc: ghc-devs@haskell.orgmailto:ghc-devs@haskell.org; Simon Peyton Jones;
Joachim Breitner
Subject: Re: let app invariant failure, HALP Re: how to write a ghc primop that
acts on an unevaluated argument?
woot, solved it, at least in a way thats OK for now.
if I mark the prefetchValue operations as has_side_effects=True, the core lint
failure goes away! I'm not sure if thats the right semantics in the long term,
but it does give me a simple way to make sure it works safely for 7.10
pardon all the noise
-Carter
On Sun, Nov 23, 2014 at 4:26 PM, Carter Schonwald
carter.schonw...@gmail.commailto:carter.schonw...@gmail.com wrote:
ok, i'm getting a let/app invariant failure
Re: help wrt semantics / primops for pure prefetches
Actually, he was already working on them. I just joined him because I've wanted to have them for a while too. I don't have a real example using the prefetch (we just got it working!) but I do have the test case we used to make sure they were implemented correctly. The code is http://lpaste.net/4551930812748005376 (I recommend using llvm when testing this but it shows the improvement either way) and, two separate runs of 5 times each: http://lpaste.net/5476270150657245184 http://lpaste.net/1229927210207412224 The first prefetches the location we're just about to look at, the second prefetches 10 lookups ahead. Its completely untunned, the GC seems to throw a bunch of garbage into the nursery but the prefetch version is notably faster. We were just using this to make sure the implementation worked so we didn't put too much effort into it. Originally we were working with binary search and speculative look-ahead, but that was far harder to maintain as the prefetch ops changed. (A bundled binary search is a lot easier of course) Sadly the early binary search results are of no use because in their early form using them created massive nursery garbage pressure when in pure code. We had one (very briefly) in IO I believe but I lack any information on it. Yes - using prefetch well is hard. Yes - the optimal use of prefetch depends on the exact CPU and memory you have. The best way to deal with this is of course to plan for it and that can be warranted with some code. Code that does a lot of random access but doesn't use too much memory bandwidth can be fairly tolerant to prefetch distance though. For example the demo should drop to near-optimal quickly and its performance should take quite a while to start dropping again. I believe on my system the nearly optimal range was around 5 untill around 40. One nice version of a prefetch that I talked to Carter about was stick the prefetch approximately the right number of instructions ahead of here I expect that is too complicated to implement though. As we don't have thunk prefetchers currently (sad), I can't give you a demo showing a speed up in the containers package, but I could write the bundled binary search demo for you if you like. On Thu, Nov 27, 2014 at 5:20 AM, Edward Kmett ekm...@gmail.com wrote: My general experience with prefetching is that it is almost never a win when done just on trees, as in the usual mark-sweep or copy-collection garbage collector walk. Why? Because the time from the time you prefetch to the time you use the data is too variable. Stack disciplines and prefetch don't mix nicely. If you want to see a win out of it you have to free up some of the ordering of your walk, and tweak your whole application to support it. e.g. if you want to use prefetching in garbage collection, the way to do it is to switch from a strict stack discipline to using a small fixed-sized queue on the output of the stack, then feed prefetch on the way into the queue rather than as you walk the stack. That paid out for me as a 10-15% speedup last time I used it after factoring in the overhead of the extra queue. Not too bad for a weekend project. =) Without that sort of known lead-in time, it works out that prefetching is usually a net loss or vanishes into the noise. As for the array ops, davean has a couple of cases w/ those for which the prefetching operations are a 20-25% speedup, which is what motivated Carter to start playing around with these again. I don't know off hand how easily those can be turned into public test cases though. -Edward On Thu, Nov 27, 2014 at 4:36 AM, Simon Marlow marlo...@gmail.com wrote: I haven't been watching this, but I have one question: does prefetching actually *work*? Do you have benchmarks (or better still, actual library/application code) that show some improvement? I admit to being slightly sceptical - when I've tried using prefetching in the GC it has always been a struggle to get something that shows an improvement, and even when I get things tuned on one machine it typically makes things slower on a different processor. And that's in the GC, doing it at the Haskell level should be even harder. Cheers, Simon On 22/11/2014 05:43, Carter Schonwald wrote: Hey Everyone, in https://ghc.haskell.org/trac/ghc/ticket/9353 and https://phabricator.haskell.org/D350 is some preliminary work to fix up how the pure versions of the prefetch primops work is laid out and prototyped. However, while it nominally fixes up some of the problems with how the current pure prefetch apis are fundamentally borken, the simple design in D350 isn't quite ideal, and i sketch out some other ideas in the associated ticket #9353 I'd like to make sure pure prefetch in 7.10 is slightly less broken than in 7.8, but either way, its pretty clear that working out the right fixed up design wont happen till 7.12. Ie, whatever makes 7.10, there WILL have to be breaking changes to fix those
superfluous ghc --make log?
This is a very minor issue, but I've been wondering if there's a rationale behind ghc --make pretty much printing the same thing thrice. Say you're building Cabal, you'll see (line wrapped for email): [ 1 of 75] Compiling Distribution.Compat.CreatePipe ( Distribution/Compat/CreatePipe.hs, Distribution/Compat/CreatePipe.o ) So, why not print [ 1 of 75] Compiling Distribution.Compat.CreatePipe instead? I'm assuming there's a good reason for the current behavior, but if there's none, are there any objections to changing what's printed? Of course, the old behavior could be re-enabled via -v. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: superfluous ghc --make log?
On 2014-11-27 at 18:32:47 +0100, Tuncer Ayaz wrote: This is a very minor issue, but I've been wondering if there's a rationale behind ghc --make pretty much printing the same thing thrice. IMO it isn't the same thing that's printed thrice. If you e.g. compile `transformers`, you'd get the following output: Preprocessing library transformers-0.4.2.0... [ 1 of 28] Compiling Data.Functor.Identity ( oldsrc/Data/Functor/Identity.hs, dist/build/Data/Functor/Identity.o ) [ 2 of 28] Compiling Control.Monad.Trans.Class ( Control/Monad/Trans/Class.hs, dist/build/Control/Monad/Trans/Class.o ) [ 3 of 28] Compiling Control.Monad.Signatures ( Control/Monad/Signatures.hs, dist/build/Control/Monad/Signatures.o ) ... there you'd see the two pathnames are not necessarily directly derivable from the module name, but depend on additional flags given to `ghc`... So it does indeed provide additional information about what GHC is doing. Btw, this also tells you whether a .hs file or a .lhs file was picked up. As to whether it's too noisy for the default verbosity level, I have no opinion (yet)... Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: let app invariant failure, HALP Re: how to write a ghc primop that acts on an unevaluated argument?
The version of the test hs file I attached might include the use of a
prefetch byte array primop. If so, commenting it out might suffice for
using it as a test case. I'll re email a corrected version later tonight
of need be. Currently amidst family travel.
On Nov 27, 2014 1:25 PM, Carter Schonwald carter.schonw...@gmail.com
wrote:
ok,
the attached output file was made using the following command
./inplace/bin/ghc-stage2 T8256.hs -O2 -dcore-lint -fforce-recomp
-ddump-simpl -dverbose-core2core -ddump-occur-anal -ddump-inlinings
output ^1
i've also attached the test hs file i used
the primop definitions i used were :
primop PrefetchValueOp0 prefetchValue0# GenPrimOp
a - State# s - State# s
with strictness = { \ _arity - mkClosedStrictSig [botDmd, topDmd]
topRes }
primop PrefetchValueOp1 prefetchValue1# GenPrimOp
a - State# s - State# s
with strictness = { \ _arity - mkClosedStrictSig [botDmd, topDmd]
topRes }
primop PrefetchValueOp2 prefetchValue2# GenPrimOp
a - State# s - State# s
with strictness = { \ _arity - mkClosedStrictSig [botDmd, topDmd]
topRes }
primop PrefetchValueOp3 prefetchValue3# GenPrimOp
a - State# s - State# s
with strictness = { \ _arity - mkClosedStrictSig [botDmd, topDmd]
topRes }
(the idea of those strictness attributes is that the operations should be
lazy in their value arg)
thanks!
-Carter
On Thu, Nov 27, 2014 at 12:03 PM, Simon Peyton Jones
simo...@microsoft.com wrote:
are you quite sure you did –dverbose-core2core –ddump-occur-anal? I
see none of that output in the file.
Regardless of the flags you set for the primop, I’m surprised that the
invariant is invalidated. Should not happen.
As well as the revised output, could you enclose a snippet of
primops.txt.pp for prefetchValue1,2,3#
S
*From:* Carter Schonwald [mailto:carter.schonw...@gmail.com]
*Sent:* 25 November 2014 06:47
*To:* Simon Peyton Jones
*Cc:* Edward Kmett; ghc-devs@haskell.org; Joachim Breitner
*Subject:* Re: let app invariant failure, HALP Re: how to write a ghc
primop that acts on an unevaluated argument?
ok attached is the log of
./inplace/bin/ghc-stage2 codetester.hs -O2 -dcore-lint -fforce-recomp
-ddump-simpl -ddump-to-file -dverbose-core2core -ddump-occur-anal
-ddump-inlinings output ^1
the relevant snippet is bellow.
It looks like the Float-Out transformation is what tripping it.
That said, reading through what the semantics are implied by
has_side_effects = True, the prefetch* family of operations ARE side
effectful with respect the fact that they DO modify the CPU cache in a way
that changes what memory locations are in various levels of CPU cache, so
despite seeming read-like, they are modifying the state of the system, just
in a way that is ONLY visible wrt the performance characteristics/runtime
of the resulting program.
specifically, Duplication, Floating out, and Specultive evaluation all
change *when* the prefetch runs and changes the CPU state, and Discard
means this mutation of the CPU cache state would not happen.
if prefetch was pure semantically (ie equiv to a - () ) , they'd just
be no op, they're exclusively a tool for performance engineering, and
accordingly when and where they appear in code matters!
i'm more than happy to write out a more detailed version of this
explanation somewhere if you like.
-Carter
*** Core Linted result of Simplifier:
*** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}):
*** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True,
OverSatApps = True}):
*** Core Lint errors : in result of Float out(FOS {Lam = Just 0,
Consts = True,
OverSatApps = True})
***
no location info: Warning:
In the expression: prefetchValue2#
@ [Char]
@ RealWorld
lvl_s3Oi
(prefetchValue1#
@ Int
@ RealWorld
lvl_s3Oj
(prefetchAddr3# @ RealWorld ds1_a3zg 0
ds_a3zf))
This argument does not satisfy the let/app invariant:
prefetchValue1#
@ Int
@ RealWorld
lvl_s3Oj
On Mon, Nov 24, 2014 at 10:43 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
huh, apparently i was mixing up '-' and some other similar dash
character, time to let my rebuild of ghc go through then try gain :)
On Mon, Nov 24, 2014 at 10:37 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
when i run
./inplace/bin/ghc-stage2 codetester.hs -O2 -dcore-lint -S
-fforce-recomp -ddump-simpl -ddump-to-file –dverbose-core2core
–ddump-occur-anal –ddump-inlinings
i get
target ‘–dverbose-core2core’ is not a
Re: Proposal: Improving the LLVM backend by packaging it
Austin Seipp aus...@well-typed.com writes: Hi *, A few days ago a discussion on IRC occurred about the LLVM backend, its current status, and what we could do to make it a rock solid part of GHC for all our users. As if we needed another reason to do this, it seems that LLVM 3.6 will backwards incompatibly change the alias grammar [1]. This would be quite nasty to treat properly in the backend's current pretty-printing framework so I think we are quickly approaching the point where tighter constraints on acceptable LLVM versions is the only path to sanity. That being said, I'm hopeful that LLVM 3.6 might finally allow us to clean up the LLVM backend. Today I finally sat down and churned out a refactoring of LLVM's prefix data [2]. This should enable a rewrite of tables-next-to-code support which will allow us to severely cut down on the size of the mangler (although sadly I suspect that some mangling will still be necessary on some platforms). I'm going to try to put together a first cut of a TNTC rework tonight. Lastly, as it turns out the LLVM 3.5 rework revealed [3] some optimization opportunties to LLVM which in turn revealed a long-hidden bug in LLVM's implementation of the GHC calling convention (at least on ARM). I've submitted a fix [4] for this as well which will hopefully make it in to LLVM 3.6. Unfortunately, the timing surrounding all of this is relatively terrible. Carter has told me that LLVM 3.6 release might happen around the time of our 7.10 release. As I mentioned above, the grammar change could make supporting both = 3.6 and 3.6 quite painful. However, given that LLVM 3.5 chokes on our code on ARM, this leaves two options for 7.10, a. Support only LLVM = 3.4 b. Support only LLVM 3.6, assuming that 3.6 is actually released in time In my opinion both of these options are pretty bad as we are left either supporting a 12-month old, buggy release or a potentially non-existent release. At the moment I'm leaning towards the latter but it's all quite unfortunate. Cheers, - Ben [1] https://github.com/bgamari/ghc/commit/6d80a4925bf6f0221076db9c691d23dd0d83eba9 [2] http://reviews.llvm.org/D6444 [3] https://phabricator.haskell.org/D155#14307 [4] http://reviews.llvm.org/D6445 pgpclDYeDlsKW.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: Improving the LLVM backend by packaging it
Late to the conversation sorry. I think this sounds like a good plan. Given we are planning to stick with a vanilla LLVM but just fix the version, it seems it should make it reasonable to have distro’s support this. We can provide binaries easily, but also just a declaration that llvm-3.4 is the current supported version, so please package that and tell GHC where to find it. We already do this in a weak way by checking which version of LLVM the user is using and issuing a warning when it’s one we don’t support. The other aspect that would be very useful is if all the build machines tested with LLVM as well. It’s a lot of work to support LLVM across all the platforms we support and to track changes across both communities. Automated testing of the currently supported LLVM version and LLVM-HEAD would be great. Cheers, David ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
