GHC-8 compatible Hackage release?

[tmcdonell]

First I just want to say thanks for all your hard work on llvm-general. I've been using it in my own work for a while and it has been great. On that note, I would like to make a 1.0 release of accelerate and accelerate-llvm to Hackage, however due to a bug in GHC-7.10 (#11108), it really requires GHC-8.

Since I am currently blocked on this, is there anything I could do to help you get GHC-8 compatible releases of llvm-general onto Hackage?

I've been using the llvm-3.8 and llvm-3.9 branches that you and @cocreature have been working on with GHC-8 for some time now, and they have been working well for me. Are these ready to be released? If not, what is left to be done or where else might I help out?

[cocreature]

This has come up before, here’s @bscarlet’s answer. So unless @bscarlet has changed his opinion the llvm-3.8 and llvm-3.9 branches won’t be released anytime soon. So I guess your best bet would be to get a GHC-8 compatible release of the 3.5 branch but I think that’s still missing GHC-8 support.

[tmcdonell]

@cocreature ah thanks for the pointer, I hadn't seen those comments. I may look into getting the 3.5 branch up to date then as you suggest.

[bscarlet]

Yes, there are two different tracks of work to get releases out.

For the 3.5 branch, we just need to get the new good stuff from the newer branches backported onto the 3.5 branch. I got a chunk of that work done on the llvm-3.5-backports branch, just working sequentially through the commits on the 3.8 branch, cherrypicking the 3.5-relevant parts. (Usually when I work, I do this cross-branch cherrypicking as I go. I didn't push on the issue when the new 3.8 work was going in, so 3.5 fell behind). It looks like I got as far as the current head of the 3.8 branch. You could look over what else needs backporting from the further work on the 3.9 branch after it forked off of 3.8.

For the later branches, I'd like to have a good idea of how they do on feature correlation with LLVM. I'd accept feature gaps - just stuff that isn't implemented (yet) - as long as it's not too big a regression from the corresponding feature coverage in the earlier branches. In the past I've done work like this by actually reviewing the diffs of the llvm language reference between releases to make sure I've caught any changes. Because the llvm C++ code often has backward compatibility glue, building against it doesn't force implementation of new features. Mostly I'd be looking for stuff like new instructions, changes to how the fiddly options for instructions work, etc. Just an analysis of where the 3.8 and 3.9 branches have wound up in that regard would tell us a lot in terms of how safe releasing would be. Ultimately I'd be happy to push releases out to get people on newer versions, I just don't want to the API we present for any given LLVM release to get too far out of sync with the reality of the language for that release.

[tmcdonell]

@bscarlet is there anything other than #198 you wanted for a LLVM-3.5/GHC-8 release? Once that is out I'll start looking at the later branches.

[ezyang]

Also, it would be nice if the bounds on llvm-general-pure-3.5.0.0 were updated so that it was marked that the package was incompatible with GHC 8.0.