Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20

[Jens Petersen]

Hi Adam,

> > > We'd like to update to Mesa 10.1 in Fedora 20, since the cycle is so
> > > long before F21 and (among other goodies) it enables OpenGL 3.3 on some
> > > newer Radeons.  This implies rebasing LLVM 3.4, and that's where it gets
> > > a little awkward: the OpenGTL package only works up to LLVM 3.3.
> > 
> > One concern from me is that ghc on ARM uses llvm as its compiler backend.
> 
> Thanks for letting me know!  ghc doesn't show up as an llvm-libs
> consumer on amd64 so I hadn't caught this.

Right - I think even on ARM only llvm would show up.

> Is it possible to build the llvm backend on other arches, even if only
> locally?  That might at least allow me to shake out issues with the llvm
> code outside of actual codegen.

It is built by default at least on intel archs - just not used by default.
GHC ARM is kind of an anomaly using llvm by default - intel archs
and ppc 32bit have (good) native code generators and so don't use
the newer llvm backend in their compilation pipeline.

You can test ghc with llvm on intel archs with the -fllvm.
What you probably want to do is to change or patch ghc-rpm-macros
locally to pass the -fllvm flag to ghc via Haskell Cabal buildsystem.
I can send you a diff for that.  Or you can tweak individual
Haskell packages to use llvm by adding:

%define cabal_configure_options --ghc-option=-fllvm

at the beginning of their %build sections.

(A more expensive way would be to rebuild all the current packages
in Rawhide which would cause them to be rebuild with llvm-3.4 on ARM,
but that is probably overkill and I hope we can move Rawhide ghc to 7.8
soon anyway)

Thanks, Jens