Re: [alpine-aports] [PATCH 1/4] testing/ghc-llvm new aport
On Sun, 12 Jun 2016 17:34:51 -0500
Mitch Tishmack <mitch.tishmack_at_gmail.com> wrote:
> 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.
can Julia and ghc share the same llvm 3.7 or do we need juila-llvm +
> > 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:
> > https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend
> > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1
> > 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.
> > mitch
> >> 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?
> >> -nc
Received on Mon Jun 13 2016 - 14:44:18 UTC