David Terei d...@davidterei.com writes:
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
Perhaps we could have ./validate also imply the 'llvm' WAY for tests
and not just the 'fast' way (which tests the NCG). But that would
double the amount of time needed for the testsuite by itself (actually
slightly more than that, since the LLVM backend is normally slower
than the NCG). But
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
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
I think this is a great idea. My understanding from the wiki page is that
the full plan involves:
1. We need to *fix compatibility with recent LLVM versions*. This really
sucks for users. *Ben Gamari* is working on this, see #9142
https://ghc.haskell.org/trac/ghc/ticket/9142 and
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.
Needless to say, the situation right now isn't so hot: we have no
commitment
Hi,
Am Samstag, den 01.11.2014, 11:43 -0400 schrieb Ben Gamari:
I'm certainly not opposed to this idea and there is precedent in this
area set by the Rust folks. That being said, I suspect some
distributions may care pretty deeply about being able to compile against
their own LLVM packaging,
On Sat, Nov 1, 2014 at 10:43 AM, Ben Gamari bgamari.f...@gmail.com wrote:
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.
Hi,
Am Samstag, den 01.11.2014, 11:05 -0500 schrieb Austin Seipp:
Do you envision that LLVM always be built alongside GHC when bringing up a
new working tree?
No - on Tier 1 platforms, I suggest we always provide binary packages
for developers to grab. Those same binaries would be
Joachim, thanks for the forward and discussion.
Just to rehash two points for the people reading at home:
- I *do not* want to ship GHC specific patches to LLVM in the builds
we use, anymore than anyone else does. I don't have any plans or even
patches I would apply right now. A stock LLVM is
On Sat, Nov 1, 2014 at 11:12 AM, Joachim Breitner
m...@joachim-breitner.de wrote:
Hi,
Am Samstag, den 01.11.2014, 11:05 -0500 schrieb Austin Seipp:
Do you envision that LLVM always be built alongside GHC when bringing up a
new working tree?
No - on Tier 1 platforms, I suggest we always
Hi,
Am Samstag, den 01.11.2014, 11:26 -0500 schrieb Austin Seipp:
How long does building those two llvm binaries take? If it is
sufficiently quick, maybe that would be a suitable distribution for
developers as well, and avoids having to separately build, distribute,
download, and install
Austin Seipp aus...@well-typed.com writes:
Joachim, thanks for the forward and discussion.
Just to rehash two points for the people reading at home:
- I *do not* want to ship GHC specific patches to LLVM in the builds
we use, anymore than anyone else does. I don't have any plans or even
Austin Seipp aus...@well-typed.com writes:
On Sat, Nov 1, 2014 at 10:43 AM, Ben Gamari bgamari.f...@gmail.com wrote:
I'm certainly not opposed to this idea and there is precedent in this
area set by the Rust folks. That being said, I suspect some
distributions may care pretty deeply about
Austin Seipp aus...@well-typed.com writes:
On Sat, Nov 1, 2014 at 11:12 AM, Joachim Breitner
m...@joachim-breitner.de wrote:
Hi,
for the Distributions it would be most easy if the custom llvm would
come within the source tarball, would be built by the regular build
process and installed
On 2014-11-01 at 17:26:26 +0100, Austin Seipp wrote:
[...]
How long does building those two llvm binaries take? If it is
sufficiently quick, maybe that would be a suitable distribution for
developers as well, and avoids having to separately build, distribute,
download, and install the
On 2014-11-01 at 18:43:35 +0100, Ben Gamari wrote:
[...]
This would mostly hurt if you cleaned up the tree later (e.g. 'make
distclean'), which I do rather frequently in order to get a pristine
build tree.
Ideally `make clean` would be a bit more complete so it could be used
more often.
Also, it could be a chance to make it easier to experiment with things like
polly: http://polly.llvm.org/
On 31 October 2014 15:18, Sophie Taylor sop...@traumapony.org wrote:
If this does happen, it'd probably make sense to use this as a chance to
refactor out the LLVM bits and use the
If this does happen, it'd probably make sense to use this as a chance to
refactor out the LLVM bits and use the llvm-general package. llvm-general
seems to only depend on base libraries (apart from parsec, which seems to
only be used for parsing data layout formats; it could probably be disabled
On Fri, 24 Oct 2014 18:52:53 -0500
Austin Seipp aus...@well-typed.com wrote:
I won't repeat what's on the wiki page too much, but the TL;DR version
is: we should start packaging a version of LLVM, and shipping it with
e.g. binary distributions of GHC. It's just a lot better for everyone.
I
On 10/25/2014 12:52 AM, Austin Seipp wrote:
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.
Needless to say, the situation right now isn't so hot: we have no
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.
Needless to say, the situation right now isn't so hot: we have no
commitment to version support, two major versions are
22 matches
Mail list logo
