Proposal: Improving the LLVM backend by packaging it

[Austin Seipp]

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.

 - If any patches _are_ needed, I'd of course like to get upstream to
accept them ASAP so they can make it into a stable release. I don't
want to maintain a patchset forever, and nobody else does either. And
I've found the LLVM developers very helpful/reasonable when submitting
patches in the past, so I imagine this will be the way we go.

I think the problem with patches, really, isn't getting them accepted
(which is easy) or even writing them (which is also sometimes pretty
easy) - it's that we have limited effort and developer time to
dedicate to this at all. We already have limited GHC hackers - the
intersection of GHC *and* LLVM hackers is even smaller.

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).

In terms of synchronization, GHC has a 1yr release vs LLVM's 6 month
release. It seems reasonable to upgrade once a year or so to match a
newer LLVM.


On Sat, Nov 1, 2014 at 10:58 AM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> 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 at joachim-breitner.de
>   Homepage: http://www.joachim-breitner.de
>   Jabber-ID: nomeata at joachim-breitner.de
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

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