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 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 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 with a compiler flag if we construct the data layout structures directly; see https://github.com/bscarlet/llvm-general/blob/5f266db5ad8015f7d79374684b083f...). It seems a more principled way than what is currently implemented, and work done to improve that library via ghc would also help every other user of the library, and visa versa.

On 27 October 2014 19:25, Sergei Trofimovich wrote:

...

On Fri, 24 Oct 2014 18:52:53 -0500 Austin Seipp 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 know we're normally fairly hesitant about things like this (shipping external dependencies), but I think it's the only sane thing to do here, and the situation is fairly unique in that it's not actually very complicated to implement or support, I think.

That makes a lot of sense! Gentoo allows user upgrade llvm and ghc independently, which makes syncing harder. Thus Gentoo does not care much about llvm support in ghc.

--

Sergei

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

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, especially if they are already shipping the same LLVM version as we require. It would be really nice to hear your thoughts on this, Joachim.

it would be nice if we would not have to do this, but if LLVM does not provide a stable enough interface I see the technical need for it. I asked the stakeholders in Debian for optinions¹ but only got one reply from the LLVM maintainer, saying:

Obviously, I don't really like code duplication on a project like LLVM. Especially since it seems like a fork.

If upstream goes this way (and I agree that it is going to be hard for the Debian maintainer of ghc to go against that), it is going to be hard for the maintainer, especially if there is no plan to sync LLVM from time to time (if they do, well, you should be quite fine, LLVM is not super hard to maintain and we can always exchange info).

However, I think upstream (ghc) should try to work more closely with LLVM and find a better way to collaborate. Having patches applied in LLVM itself is simple and usually fast.

BTW, there are discussion on LLVM mailing list on this topic.

So, I am not going to give a green or red light. I don't think this is going to affect my work... Mostly, it is going to affect yours.

So the Debian packaging will just follow whatever upstream does here. Greetings, Joachim ¹ https://lists.debian.org/debian-haskell/2014/10/msg00017.html -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata@joachim-breitner.de

Austin Seipp 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 patches I would apply right now. A stock LLVM is ideal - one that's just been picked to work well by us. Even if it has some bugs or workarounds are needed, that's probably OK.

I agree. Shipping a known-stable LLVM is one thing; patching our own LLVM is quite another. Patching LLVM should be avoided if at all possible. Thankfully LLVM is quite modular so this shouldn't be so difficult. [snip]

I'd love to work more with LLVM upstream to fix problems... but the time to do so is pretty limited for most of us, I think, and the current backend has real issues in the design that cooperation just can't fundamentally fix - cooperation can't fix the fact a new release may change IR semantics and break existing GHC releases, for example. Users will simply suffer from that. And some of those changes may not be totally trivial to accommodate (as Ben's recent work shows).

While this is technically true I wonder whether IR changes will be a persistent problem going forward. I don't have a deep knowledge of the history of the LLVM IR but my impression is that the maintainers are fairly deliberate in their consideration of sematic changes (despite the arguable `symbol_offset` and `prefix_data` mis-step in 3.5). The alias change was an unexpected turn but frankly our previous use of aliases was a bit odd and was never supposed to work in the first place (something is amiss when you are relying on the optimizer to elide aliases to produce valid code). The alias rework and (hopefully) upcoming TNTC rework make me optimistic that our use of LLVM moving closer to how the interfaces are designed to be used. Hopefully this will be accompanied by a corresponding improvement in maintainability. There are other reasons besides IR instability that we might want to distribute our own LLVM. These might include, * Decoupling GHC from changes in LLVM's optimization passes * Wanting to ship own optimization passes that need to link against LLVM. * Wanting to use a library like llvm-general in GHC * Wanting to use leverage related libraries such as Polly I'm not sure how these weigh against the maintenance and packaging costs of shipping our own LLVM. I've not seen evidence that changes in LLVM's optimizer have hurt us in the past; then again if we are going to be more selective about which optimizations we ask LLVM to perform perhaps this will become a bigger concern in the future. Shipping our own passes would be great and is probably necessary to continue to improve performance. It not clear whether LLVM's analysis pass interface is stable enough to facilitate this without shipping our own LLVM. Max's analysis is now three years old; I'll try dusting off the code and see how bad the damage is. It's not clear to me that we really want to add a dependency on another library to GHC. Being able to leverage things like Polly sounds tempting but adding another moving part to LlvmGen will likely incur a maintenance cost. Moreover, the fact that there still isn't a llvm-general release targeting LLVM 3.5 is a bit worrying. As a quite note, I spoke briefly with a few Rustaceans and they report that they were hoping to ultimately avoid shipping an LLVM with rustc. At this point Rust doesn't have an active packaging effort so perhaps the rustc precedent isn't as useful as I originally thought. Cheers, - Ben

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 shipped with the actual binary distributions we create.

On Tier 2 platforms, people may have to compile things, but we can provide some guidelines (and perhaps utilities/scripts) to help manage this.

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 along with GHC, in a private path (/usr/lib/ghc/somewhere). We certainly don’t want to have a separate packaging with separate binary packages "llvm-ghc" around. 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 binaries. Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata@joachim-breitner.de

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 the binaries.

In practice it takes a while... I haven't timed it, but I'd guess on average it adds about 30-40 minutes for most people just to build llvm. I'm not sure how many things we can disable to make the build faster, but I'd ballpark it at half an hour at best (it's a few thousand source files, after all).

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.

yes, me too. Which means that we’d have to go through the trouble of distributing binaries... But then: Do GHC developers actually need the LLVM binaries (unless they want to test the llvm backend, of course)? Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

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. Much of my use of `make distclean` comes from superstition after thinking `make clean` would be sufficient only to find out half-way through the build that there is still vestigal state hanging around.

I regularly run ./validate, which by definition has to reset everything to a zero-state. Moreover, I keep a few GHC source-trees around, and wouldn't want to have to keep redundant LLVM binaries around. So using 'make clean' isn't an option for everyone. I'd rather install the required LLVM version system-wide (or rather, reachable via PATH), and have ./configure try to pick that one up, before deciding it needs to build its own LLVM.

Austin Seipp writes:

On Sat, Nov 1, 2014 at 10:43 AM, Ben Gamari 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 being able to compile against their own LLVM packaging, especially if they are already shipping the same LLVM version as we require. It would be really nice to hear your thoughts on this, Joachim.

Yes, this is a worry of mine too.

...

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 shipped with the actual binary distributions we create.

Good. That would greatly improve the ease-of-building. That being said, we'll also need to have logic in the build system to build LLVM from source as the Debian packaging guidelines prohibit the packaging rules From downloading binaries, IIRC. Unfortunately my cursory look didn't turn up any language in the packaging policy[1] to support this.

On Tier 2 platforms, people may have to compile things, but we can provide some guidelines (and perhaps utilities/scripts) to help manage this.

Good, I suppose the Debian packaging could just use these. Cheers, - Ben [1] https://www.debian.org/doc/debian-policy/ch-source.html#s-standardsversion

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 anyway, there are opportunities for speed ups anyway I imagine, and future Harbormaster improvements mean we could do the llvm WAY concurrently on a separate machine. On Fri, Nov 28, 2014 at 9:52 AM, Ben Gamari wrote:

David Terei 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 also just a declaration that llvm-3.4 is the current supported version, so please package that and tell GHC where to find it.

Agreed.

...

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.

Absolutely, this would be amazing. I generally don't find out about regressions due to LLVM until I have time to build and test a snapshot which doesn't happen nearly as often as I would like.

Cheers,

- Ben

-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/