Content-Type: text/plain; charset=utf-8
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: [alpine-aports] [PATCH 1/4] testing/ghc-llvm new aport
From: Mitch Tishmack <mitch.tishmack@gmail.com>
In-Reply-To: <C04E32ED-EF7D-41C2-B7A8-F443828CEEBC@gmail.com>
Date: Sun, 12 Jun 2016 17:34:51 -0500
Cc: alpine-aports@lists.alpinelinux.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <BA3A6E77-2F8E-4219-BCB6-47D29BAF694E@gmail.com>
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> <C04E32ED-EF7D-41C2-B7A8-F443828CEEBC@gmail.com>
To: Natanael Copa <ncopa@alpinelinux.org>

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=E2=80=99t 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.

Thanks!
mitch

> On May 16, 2016, at 8:31 AM, Mitch Tishmack <mitch.tishmack@gmail.com> =
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=E2=80=99ll 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=E2=80=99t =
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=E2=80=99t =
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=E2=80=99ve hit this exact case with llvm 3.5 and arm =
codegen.
> - Don=E2=80=99t support arm for ghc very well or realistically at all =
and just use system llvm
> Pros: Don=E2=80=99t 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=E2=80=99m 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=E2=80=99m not a fan of having to support/maintain a port of =
llvm, its the least horrible option of the above three.
>=20
> mitch
>> On May 16, 2016, at 4:11 AM, Natanael Copa <ncopa@alpinelinux.org> =
wrote:
>>=20
>> On Sun, 15 May 2016 22:30:15 -0500
>> Mitch Tishmack <mitch.tishmack@gmail.com> 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
>> Why cannot we use the system llvm?
>>=20
>> -nc
>=20



---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---