Re: [alpine-aports] [PATCH 1/4] testing/ghc-llvm new aport
Just a friendly reminder/ping on this patch series. Is there any action I should be taking to move getting this port merged or moving forward? With whom could I work with to get things progressing assuming there are no issues?
A note on llvm, I note that Julia also has a dependency on llvm 3.7 like ghc in that 3.8 isn’t supported. Given that llvm 3.7 was skipped over from 3.3->3.4 I think that gives a few good reasons for having a llvm-$version package for things that cannot realistically depend on the system llvm as it may change too often.
> On May 16, 2016, at 8:31 AM, Mitch Tishmack <mitch.tishmack_at_gmail.com> wrote:
> The shorter answer is:
> As of today it could if llvm were 3.7.1 (note 3.3 currently ships llvm 3.6.2 which does not work with ghc 8.0.1 at all due to arm codegen bugs), in the future it will likely break on arm when llvm itself is upgraded to newer releases.
> The longer answer is a bit more complex and nuanced.
> Two useful links that I’ll expect are read/understood first one more than the latter:
> Lets back time up to my prior ghc 7.10.3 port which didn’t support arm. Ghc 7.10 requires llvm 3.5.2, which last existed in alpine linux 3.1. While I managed to get ghc 7.10.3 to work with llvm 3.6, it was very much a frankenbuild and even after all the work, didn’t work on arm anyway. I also ran into bugs in both llvm itself, and ghc when trying to get the port working on arm. x86_64 worked fine, but x86_64 has a legacy code generator it can use along with llvm so that is more a case of happy accident.
> Needless to say there are three competing release and development schedules that make system llvm a rather unappealing target:
> - ghc
> - llvm
> - alpine linux
> While today it may be fine to use the system llvm, when llvm is upgraded to 3.8, or 3.9, or 3.9 + N, there is no guarantee that the llvm optimizer may not change how it optimizes llvm ir. Indeed the ir format may change as has happened as recently as the 3.4->3.5 transition.
> So all roads lead to Rome here in having bad choices all around. Basically:
> - Try to hack ghc to support newer versions of llvm.
> Pros: uses system llvm
> Cons: likely to break, also likely to produce subtlely broken executables as ghc version X is only ever used/tested with the llvm it is released with. I’ve hit this exact case with llvm 3.5 and arm codegen.
> - Don’t support arm for ghc very well or realistically at all and just use system llvm
> Pros: Don’t need to worry about llvm version changes if we stick to just x86_64 and consider arm a free for all.
> Cons: Well arm support in this case is basically a crapshoot. I note this only for completeness.
> - Compile llvm 3.7.1 and have a versioned port that could be depended upon in the future for when newer llvm releases are out.
> Pros: Ghc is freed from system llvm upgrades requiring patching ghc to function on arm. (note, there is no guarantee that patching ghc to support future llvm will be possible even)
> Cons: I have to basically support ghc and llvm for it.
> While I’m not hugely happy with the latter option, it is the most reasonable given the constraints of 3 competing release schedules and the reality of llvm ir not being forward or backward compatible.
> While I’m not a fan of having to support/maintain a port of llvm, its the least horrible option of the above three.
>> On May 16, 2016, at 4:11 AM, Natanael Copa <ncopa_at_alpinelinux.org> wrote:
>> On Sun, 15 May 2016 22:30:15 -0500
>> Mitch Tishmack <mitch.tishmack_at_gmail.com> wrote:
>>> testing/ghc-llvm/APKBUILD | 169 +++++++++++++++++++++++++++
>>> testing/ghc-llvm/llvm-0002-musl-triple.patch | 90 ++++++++++++++
>>> testing/ghc-llvm/llvm-0003-musl-hacks.patch | 114 ++++++++++++++++++
>>> 3 files changed, 373 insertions(+)
>>> create mode 100755 testing/ghc-llvm/APKBUILD
>>> create mode 100644 testing/ghc-llvm/llvm-0002-musl-triple.patch
>>> create mode 100644 testing/ghc-llvm/llvm-0003-musl-hacks.patch
>> Why cannot we use the system llvm?
Received on Sun Jun 12 2016 - 17:34:51 UTC