X-Original-To: alpine-aports@lists.alpinelinux.org Received: from newmail.tetrasec.net (unknown [172.21.74.12]) by lists.alpinelinux.org (Postfix) with ESMTP id 1B2FB5C40F6 for ; Mon, 13 Jun 2016 12:44:26 +0000 (GMT) Received: from ncopa-desktop.alpinelinux.org (12.63.200.37.customer.cdi.no [37.200.63.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: n@tanael.org) by newmail.tetrasec.net (Postfix) with ESMTPSA id 72D265A084C; Mon, 13 Jun 2016 12:44:25 +0000 (GMT) Date: Mon, 13 Jun 2016 14:44:18 +0200 From: Natanael Copa To: Mitch Tishmack Cc: alpine-aports@lists.alpinelinux.org Subject: Re: [alpine-aports] [PATCH 1/4] testing/ghc-llvm new aport Message-ID: <20160613144418.7c290454@ncopa-desktop.alpinelinux.org> In-Reply-To: References: <1463369418-51523-1-git-send-email-mitch.tishmack@gmail.com> <1463369418-51523-2-git-send-email-mitch.tishmack@gmail.com> <20160516111124.663becd2@ncopa-desktop.alpinelinux.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.28; x86_64-alpine-linux-musl) X-Mailinglist: alpine-aports Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, 12 Jun 2016 17:34:51 -0500 Mitch Tishmack 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 issu= es? >=20 > 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 + ghc-llvm? -nc >=20 > Thanks! > mitch >=20 > > On May 16, 2016, at 8:31 AM, Mitch Tishmack > > wrote: > >=20 > > 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. > >=20 > > The longer answer is a bit more complex and nuanced. > >=20 > > 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 > >=20 > > 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. > >=20 > > Needless to say there are three competing release and development > > schedules that make system llvm a rather unappealing target: > > - ghc > > - llvm > > - alpine linux > >=20 > > 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. > >=20 > > So all roads lead to Rome here in having bad choices all around. > > Basically: > > - Try to hack ghc to support newer versions of llvm.=20 > > Pros: uses system llvm=20 > > 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. > >=20 > > 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. > >=20 > > While I*m not a fan of having to support/maintain a port of llvm, > > its the least horrible option of the above three. > >=20 > > mitch =20 > >> On May 16, 2016, at 4:11 AM, Natanael Copa > >> wrote: > >>=20 > >> On Sun, 15 May 2016 22:30:15 -0500 > >> Mitch Tishmack wrote: > >> =20 > >>> --- > >>> 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 =20 > >>=20 > >> Why cannot we use the system llvm? > >>=20 > >> -nc =20 > > =20 >=20 --- Unsubscribe: alpine-aports+unsubscribe@lists.alpinelinux.org Help: alpine-aports+help@lists.alpinelinux.org ---