~alpine/aports

4 2

[alpine-aports] [PATCH 1/4] testing/ghc-llvm new aport

Mitch Tishmack
Details
Message ID
<1463369418-51523-2-git-send-email-mitch.tishmack@gmail.com>
Sender timestamp
1463369415
DKIM signature
missing
Download raw message
Patch: +373 -0
---
 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

diff --git a/testing/ghc-llvm/APKBUILD b/testing/ghc-llvm/APKBUILD
new file mode 100755
index 0000000..aeb3726
--- /dev/null
+++ b/testing/ghc-llvm/APKBUILD
@@ -0,0 +1,169 @@
+# Maintainer: Mitch Tishmack <mitch.tishmack@gmail.com>
+#
+# Note, this ONLY compiles llvm for opt/llc and moves the
+# suffixed binaries to /usr/lib/ghc
+#
+# This allows the ghc/ghc-bootstrap portx to use the correct llvm.
+_pkgname=llvm
+llvm_major=3.7
+llvm_version=${llvm_major}.1
+suffix="-${llvm_major}"
+opt=opt${suffix}
+llc=llc${suffix}
+pkgname=ghc-${_pkgname}
+# Allow for multiple installs, intentionally not default.
+if [ ! -z $MULTI ]; then
+	replaces=${pkgname}
+	pkgname=${pkgname}-${llvm_major}
+fi
+pkgver=$llvm_version
+pkgrel=0
+pkgdesc="ghc required llvm binaries"
+url="n/a"
+arch="x86_64 armhf"
+license="UIO-NCSA"
+depends=""
+install=""
+subpackages=""
+# llvm build dependencies
+makedepends="
+        $depends
+        $makedepends
+        perl
+        cmake
+        make
+        flex
+        bison
+        groff
+        musl-dev
+        binutils-dev
+        libffi-dev
+        zlib-dev
+        ncurses-dev
+        python
+        python-dev
+        gmp-dev
+        git
+        libtool
+        autoconf
+        automake
+        "
+_builddir="$srcdir/$pkgname-$pkgver"
+source="
+	llvm-0002-musl-triple.patch
+        llvm-0003-musl-hacks.patch
+	http://llvm.org/releases/$pkgver/llvm-$pkgver.src.tar.xz
+	http://llvm.org/releases/$pkgver/polly-$pkgver.src.tar.xz
+	"
+_builddir="$srcdir"/build
+llvm_srcdir="$srcdir/llvm-$llvm_version.src"
+llvm_builddir="$srcdir/build"
+srcdir_polly="$srcdir"/polly-$llvm_version.src
+
+_cmake_flags="\
+        -DCMAKE_BUILD_TYPE=Release \
+        -DCMAKE_VERBOSE_MAKEFILE=NO \
+        -DLLVM_DEFAULT_TARGET_TRIPLE=$CBUILD \
+        -DLLVM_HOST_TRIPLE=$CHOST \
+        -DLLVM_BINUTILS_INCDIR=/usr/include \
+        -DLLVM_ENABLE_ASSERTIONS=NO \
+        -DLLVM_ENABLE_LIBCXX=NO \
+        -DLLVM_ENABLE_PIC=YES \
+        -DLLVM_ENABLE_ZLIB=YES \
+        -DLLVM_ENABLE_RTTI=YES \
+        -DLLVM_BUILD_EXAMPLES=NO \
+        -DLLVM_INCLUDE_EXAMPLES=NO \
+        -DCMAKE_INSTALL_PREFIX=/usr \
+        -DLLVM_TARGETS_TO_BUILD='all' \
+        -DLLVM_BUILD_EXTERNAL_COMPILER_RT=NO \
+        -DBUILD_SHARED_LIBS=NO \
+        -DLLVM_BUILD_DOCS=NO \
+        -DLLVM_BUILD_TESTS=NO \
+        -DLLVM_ENABLE_CXX1Y=NO \
+        -DLLVM_ENABLE_FFI=YES \
+        -DLLVM_ENABLE_SPHINX=NO \
+        -DLLVM_ENABLE_TERMINFO=YES \
+        -DWITH_POLLY=YES \
+        -DLLVM_INCLUDE_EXAMPLES=NO \
+        -DLLVM_INCLUDE_TESTS=NO \
+        -DLLVM_ENABLE_TERMINFO=NO \
+        "
+
+prepare() {
+        msg "Patching LLVM core..."
+        cd "$llvm_srcdir" || return 1
+        for i in $source; do
+                case $i in
+                llvm-*.patch)
+                        msg "Applying $i..."
+                        patch -s -p1 -N -i "$srcdir"/$i || return 1
+                        ;;
+                esac
+        done
+}
+
+build() {
+        tmp="$srcdir/tmp"
+        install -d ${tmp} || return 1
+        mv "$srcdir"/polly-$llvm_version.src ""$llvm_srcdir"/tools/polly" || return 1
+        (
+                OCFLAGS="${CFLAGS}"
+                OCXXFLAGS="${CXXFLAGS}"
+                unset CFLAGS
+                unset CXXFLAGS
+
+                test -z "${OCFLAGS}" && OCFLAGS="-O3"
+                test -z "${OCXXFLAGS}" && OCXXFLAGS="-O3"
+
+                cflags="${OCFLAGS} -DNDEBUG -I$srcdir/tmp/include"
+                cxxflags="${OCXXFLAGS} -DNDEBUG -fno-devirtualize"
+
+                export CBUILD
+
+                ffi_include_dir="$(pkg-config --cflags-only-I libffi | sed 's|^-I||g')"
+
+                cflags="${OCFLAGS} -DNDEBUG"
+                cxxflags="${OCXXFLAGS} -DNDEBUG"
+                CC="gcc"
+                CXX="g++"
+
+                msg "Compiling llvm"
+                mkdir -p "${llvm_builddir}"
+                cd "${llvm_builddir}"
+                cmake -G "Unix Makefiles" -Wno-dev ${_cmake_flags} \
+                        -DCMAKE_C_COMPILER="${CC}" \
+                        -DCMAKE_CXX_COMPILER="${CXX}" \
+                        -DCMAKE_C_FLAGS_RELEASE="${cflags}" \
+                        -DCMAKE_CXX_FLAGS_RELEASE="${cxxflags}" \
+                        -DCMAKE_EXE_LINKER_FLAGS="${LDFLAGS} -L$srcdir/tmp/lib -static" \
+                        -DCMAKE_SHARED_LINKER_FLAGS="${LDFLAGS}" \
+                        -DFFI_INCLUDE_DIR="$ffi_include_dir" \
+                        -DCMAKE_PREFIX_PATH="$srcdir/tmp" \
+                        "${llvm_srcdir}" || return 1
+
+                (
+                        export LD_LIBRARY_PATH="$srcdir/tmp/lib:$LD_LIBRARY_PATH"
+                        make llvm-tblgen llc opt|| return 1
+                ) || return 1
+        ) || return 1
+}
+
+package() {
+        cd "$_builddir"
+        install -d "$pkgdir/usr/lib/ghc"
+        for x in opt llc; do
+                install -Dm755 "$srcdir/build/bin/${x}" "$pkgdir/usr/lib/ghc/${x}${suffix}" || return 1
+        done
+}
+md5sums="7fc6f417edec0cd7792df58386396b7d  llvm-0002-musl-triple.patch
+f57e1e394bb9b1bdb809dc5b2a8bf04e  llvm-0003-musl-hacks.patch
+bf8b3a2c79e61212c5409041dfdbd319  llvm-3.7.1.src.tar.xz
+3a2a7367002740881637f4d47bca4dc3  polly-3.7.1.src.tar.xz"
+sha256sums="4aa20d16e6afb41a2e6fd916dab9aec28acbf4f7f732524a755973c57daecde1  llvm-0002-musl-triple.patch
+028916482184cc29ca2bca4fd59a1cae2c61ee591e3d40fd4e3e9e472629da89  llvm-0003-musl-hacks.patch
+be7794ed0cec42d6c682ca8e3517535b54555a3defabec83554dbc74db545ad5  llvm-3.7.1.src.tar.xz
+ce9273ad315e1904fd35dc64ac4375fd592f3c296252ab1d163b9ff593ec3542  polly-3.7.1.src.tar.xz"
+sha512sums="e136731a82d52b70267c8fc8fdc35340406be577cd26188b0d8273fa3059d5606c4a3f618b02a99820b601dcf86bc3cb1ff9420be463521d978b5dda7764e6e8  llvm-0002-musl-triple.patch
+fdd08d4b380d1310282f4d1ee2c5c7b91246346bb275928233fd8a90d2b4c1599556af1f7d7c278fdf13faeee11ac7800ab2912a6e88dba0c9e8f6d906691e0f  llvm-0003-musl-hacks.patch
+ac521debc02f6deba96ef975d6a546b0c5c77299c1dbf5e1b87a7974ff5e7fd715bd7e384b92d9adf572ce47130bdbf6d3c648eb0d7f72f16f976292e4909e90  llvm-3.7.1.src.tar.xz
+f03a794ab85d587511653e0799c3f2ba95145762552741959decc42cde7f7f5bd80caf79c0169440b7e5d16d3bf895501387d5094f531386d74b6c3e4fe6b1e0  polly-3.7.1.src.tar.xz"
diff --git a/testing/ghc-llvm/llvm-0002-musl-triple.patch b/testing/ghc-llvm/llvm-0002-musl-triple.patch
new file mode 100644
index 0000000..2f6fd59
--- /dev/null
+++ b/testing/ghc-llvm/llvm-0002-musl-triple.patch
@@ -0,0 +1,90 @@
+From 58be6f7fb164dbf42fdd28ce6474dbe4bc5ca401 Mon Sep 17 00:00:00 2001
+From: Andrea Brancaleoni <miwaxe@gmail.com>
+Date: Tue, 8 Sep 2015 21:53:42 +0200
+Subject: [PATCH 2/3] musl triple
+
+---
+ include/llvm/ADT/Triple.h           | 4 ++++
+ lib/Support/Triple.cpp              | 6 ++++++
+ lib/Target/ARM/ARMSubtarget.h       | 3 +++
+ lib/Target/ARM/ARMTargetMachine.cpp | 2 ++
+ 4 files changed, 15 insertions(+)
+
+diff --git a/include/llvm/ADT/Triple.h b/include/llvm/ADT/Triple.h
+index 947812d..d2a6bbe 100644
+--- a/include/llvm/ADT/Triple.h
+@@ -167,6 +167,10 @@ public:
+     EABIHF,
+     Android,
+ 
++    Musl,
++    MuslEABI,
++    MuslEABIHF,
++
+     MSVC,
+     Itanium,
+     Cygnus,
+diff --git a/lib/Support/Triple.cpp b/lib/Support/Triple.cpp
+index c6646fb..8d47ad9 100644
+--- a/lib/Support/Triple.cpp
+@@ -192,6 +192,9 @@ const char *Triple::getEnvironmentTypeName(EnvironmentType Kind) {
+   case CODE16: return "code16";
+   case EABI: return "eabi";
+   case EABIHF: return "eabihf";
++  case Musl: return "musl";
++  case MuslEABIHF: return "musleabihf";
++  case MuslEABI: return "musleabi";
+   case Android: return "android";
+   case MSVC: return "msvc";
+   case Itanium: return "itanium";
+@@ -427,6 +430,9 @@ static Triple::EnvironmentType parseEnvironment(StringRef EnvironmentName) {
+     .StartsWith("code16", Triple::CODE16)
+     .StartsWith("gnu", Triple::GNU)
+     .StartsWith("android", Triple::Android)
++    .StartsWith("musleabihf", Triple::MuslEABIHF)
++    .StartsWith("musleabi", Triple::MuslEABI)
++    .StartsWith("musl", Triple::Musl)
+     .StartsWith("msvc", Triple::MSVC)
+     .StartsWith("itanium", Triple::Itanium)
+     .StartsWith("cygnus", Triple::Cygnus)
+diff --git a/lib/Target/ARM/ARMSubtarget.h b/lib/Target/ARM/ARMSubtarget.h
+index dd101df..c5bdcca 100644
+--- a/lib/Target/ARM/ARMSubtarget.h
+@@ -381,8 +381,10 @@ public:
+   bool isTargetEHABICompatible() const {
+     return (TargetTriple.getEnvironment() == Triple::EABI ||
+             TargetTriple.getEnvironment() == Triple::GNUEABI ||
++            TargetTriple.getEnvironment() == Triple::MuslEABI ||
+             TargetTriple.getEnvironment() == Triple::EABIHF ||
+             TargetTriple.getEnvironment() == Triple::GNUEABIHF ||
++            TargetTriple.getEnvironment() == Triple::MuslEABIHF ||
+             TargetTriple.getEnvironment() == Triple::Android) &&
+            !isTargetDarwin() && !isTargetWindows();
+   }
+@@ -391,6 +393,7 @@ public:
+     // FIXME: this is invalid for WindowsCE
+     return TargetTriple.getEnvironment() == Triple::GNUEABIHF ||
+            TargetTriple.getEnvironment() == Triple::EABIHF ||
++           TargetTriple.getEnvironment() == Triple::MuslEABIHF ||
+            isTargetWindows();
+   }
+   bool isTargetAndroid() const {
+diff --git a/lib/Target/ARM/ARMTargetMachine.cpp b/lib/Target/ARM/ARMTargetMachine.cpp
+index 93495d6..56e6b7f 100644
+--- a/lib/Target/ARM/ARMTargetMachine.cpp
+@@ -97,6 +97,8 @@ computeTargetABI(const Triple &TT, StringRef CPU,
+     case llvm::Triple::GNUEABIHF:
+     case llvm::Triple::EABIHF:
+     case llvm::Triple::EABI:
++    case llvm::Triple::MuslEABI:
++    case llvm::Triple::MuslEABIHF:
+       TargetABI = ARMBaseTargetMachine::ARM_ABI_AAPCS;
+       break;
+     case llvm::Triple::GNU:
+-- 
+2.5.1
+
diff --git a/testing/ghc-llvm/llvm-0003-musl-hacks.patch b/testing/ghc-llvm/llvm-0003-musl-hacks.patch
new file mode 100644
index 0000000..d88b5fc
--- /dev/null
+++ b/testing/ghc-llvm/llvm-0003-musl-hacks.patch
@@ -0,0 +1,114 @@
+From faca3fbd15d0c3108493c3c54cd93138e049ac43 Mon Sep 17 00:00:00 2001
+From: Andrea Brancaleoni <miwaxe@gmail.com>
+Date: Tue, 8 Sep 2015 22:03:02 +0200
+Subject: [PATCH 3/3] musl
+
+---
+ include/llvm/Analysis/TargetLibraryInfo.h | 9 +++++++++
+ lib/Analysis/TargetLibraryInfo.cpp        | 5 +++--
+ lib/Support/DynamicLibrary.cpp            | 2 +-
+ lib/Support/Unix/Signals.inc              | 6 +++---
+ utils/unittest/googletest/src/gtest.cc    | 1 +
+ 5 files changed, 17 insertions(+), 6 deletions(-)
+
+diff --git a/include/llvm/Analysis/TargetLibraryInfo.h b/include/llvm/Analysis/TargetLibraryInfo.h
+index e0a1ee3..465b65a 100644
+--- a/include/llvm/Analysis/TargetLibraryInfo.h
+@@ -18,6 +18,15 @@
+ #include "llvm/IR/Module.h"
+ #include "llvm/Pass.h"
+ 
++#undef fopen64
++#undef fseeko64
++#undef fstat64
++#undef fstatvfs64
++#undef ftello64
++#undef lstat64
++#undef stat64
++#undef tmpfile64
++
+ namespace llvm {
+ /// VecDesc - Describes a possible vectorization of a function.
+ /// Function 'VectorFnName' is equivalent to 'ScalarFnName' vectorized
+diff --git a/lib/Analysis/TargetLibraryInfo.cpp b/lib/Analysis/TargetLibraryInfo.cpp
+index 635c50c..863f4a0 100644
+--- a/lib/Analysis/TargetLibraryInfo.cpp
+@@ -336,14 +336,15 @@ static void initialize(TargetLibraryInfoImpl &TLI, const Triple &T,
+   }
+ 
+   // The following functions are available on at least Linux:
+-  if (!T.isOSLinux()) {
++  if (!T.isOSLinux())
++    TLI.setUnavailable(LibFunc::memalign);
++  if (1 /*!T.isGlibc()*/) {
+     TLI.setUnavailable(LibFunc::dunder_strdup);
+     TLI.setUnavailable(LibFunc::dunder_strtok_r);
+     TLI.setUnavailable(LibFunc::dunder_isoc99_scanf);
+     TLI.setUnavailable(LibFunc::dunder_isoc99_sscanf);
+     TLI.setUnavailable(LibFunc::under_IO_getc);
+     TLI.setUnavailable(LibFunc::under_IO_putc);
+-    TLI.setUnavailable(LibFunc::memalign);
+     TLI.setUnavailable(LibFunc::fopen64);
+     TLI.setUnavailable(LibFunc::fseeko64);
+     TLI.setUnavailable(LibFunc::fstat64);
+diff --git a/lib/Support/DynamicLibrary.cpp b/lib/Support/DynamicLibrary.cpp
+index 9a7aeb5..e21750d 100644
+--- a/lib/Support/DynamicLibrary.cpp
+@@ -138,7 +138,7 @@ void* DynamicLibrary::SearchForAddressOfSymbol(const char *symbolName) {
+ 
+ // This macro returns the address of a well-known, explicit symbol
+ #define EXPLICIT_SYMBOL(SYM) \
+-   if (!strcmp(symbolName, #SYM)) return &SYM
++   if (!strcmp(symbolName, #SYM)) return (void *) &SYM
+ 
+ // On linux we have a weird situation. The stderr/out/in symbols are both
+ // macros and global variables because of standards requirements. So, we
+diff --git a/lib/Support/Unix/Signals.inc b/lib/Support/Unix/Signals.inc
+index bfe2a3a..e8372d9 100644
+--- a/lib/Support/Unix/Signals.inc
+@@ -117,7 +117,7 @@ static void RegisterHandlers() {
+   // during handling an actual signal because you can't safely call new in a
+   // signal handler.
+   *SignalsMutex;
+-  
++
+   // If the handlers are already registered, we're done.
+   if (NumRegisteredSignals != 0) return;
+ 
+@@ -164,7 +164,7 @@ static void RemoveFilesToRemove() {
+     // super-user permissions.
+     if (!S_ISREG(buf.st_mode))
+       continue;
+-  
++
+     // Otherwise, remove the file. We ignore any errors here as there is nothing
+     // else we can do.
+     unlink(path);
+@@ -430,7 +430,7 @@ static bool printSymbolizedStackTrace(void **StackTrace, int Depth,
+ // On glibc systems we have the 'backtrace' function, which works nicely, but
+ // doesn't demangle symbols.
+ void llvm::sys::PrintStackTrace(raw_ostream &OS) {
+-#if defined(HAVE_BACKTRACE) && defined(ENABLE_BACKTRACES)
++#if defined(__GLIBC__) && defined(HAVE_BACKTRACE) && defined(ENABLE_BACKTRACES)
+   static void* StackTrace[256];
+   // Use backtrace() to output a backtrace on Linux systems with glibc.
+   int depth = backtrace(StackTrace,
+diff --git a/utils/unittest/googletest/src/gtest.cc b/utils/unittest/googletest/src/gtest.cc
+index 5780764..1d548c1 100644
+--- a/utils/unittest/googletest/src/gtest.cc
+@@ -120,6 +120,7 @@
+ 
+ #if GTEST_CAN_STREAM_RESULTS_
+ # include <arpa/inet.h>  // NOLINT
++# include <sys/socket.h>  // NOLINT
+ # include <netdb.h>  // NOLINT
+ #endif
+ 
+-- 
+2.5.1
+
-- 
2.8.0



---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Mitch Tishmack
Details
Message ID
<C04E32ED-EF7D-41C2-B7A8-F443828CEEBC@gmail.com>
In-Reply-To
<20160516111124.663becd2@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1463405495
DKIM signature
missing
Download raw message
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@alpinelinux.org> wrote:
> 
> On Sun, 15 May 2016 22:30:15 -0500
> Mitch Tishmack <mitch.tishmack@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



---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Natanael Copa
Details
Message ID
<20160516111124.663becd2@ncopa-desktop.alpinelinux.org>
In-Reply-To
<1463369418-51523-2-git-send-email-mitch.tishmack@gmail.com> (view parent)
Sender timestamp
1463389884
DKIM signature
missing
Download raw message
On Sun, 15 May 2016 22:30:15 -0500
Mitch Tishmack <mitch.tishmack@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


---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Mitch Tishmack
Details
Message ID
<BA3A6E77-2F8E-4219-BCB6-47D29BAF694E@gmail.com>
In-Reply-To
<C04E32ED-EF7D-41C2-B7A8-F443828CEEBC@gmail.com> (view parent)
Sender timestamp
1465770891
DKIM signature
missing
Download raw message
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.

Thanks!
mitch

> On May 16, 2016, at 8:31 AM, Mitch Tishmack <mitch.tishmack@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@alpinelinux.org> wrote:
>> 
>> On Sun, 15 May 2016 22:30:15 -0500
>> Mitch Tishmack <mitch.tishmack@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
> 



---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Natanael Copa
Details
Message ID
<20160613144418.7c290454@ncopa-desktop.alpinelinux.org>
In-Reply-To
<BA3A6E77-2F8E-4219-BCB6-47D29BAF694E@gmail.com> (view parent)
Sender timestamp
1465821858
DKIM signature
missing
Download raw message
On Sun, 12 Jun 2016 17:34:51 -0500
Mitch Tishmack <mitch.tishmack@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 +
ghc-llvm?

-nc

> 
> Thanks!
> mitch
> 
> > On May 16, 2016, at 8:31 AM, Mitch Tishmack
> > <mitch.tishmack@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@alpinelinux.org>
> >> wrote:
> >> 
> >> On Sun, 15 May 2016 22:30:15 -0500
> >> Mitch Tishmack <mitch.tishmack@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  
> >   
> 



---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---