Clean up opt and llc

Authored by angerman on Sep 6 2017, 10:31 AM.


Clean up opt and llc

The LLVM backend shells out to LLVMs opt and llc tools. This clean
up introduces a shared data structure to carry the arguments we pass to
each tool so that corresponding flags are next to each other. It drops
the hard coded data layouts in favor of using -mtriple and have LLVM
infer them. Furthermore we add clang as a proper tool, so we don't
rely on assuming that clang is called clang on the PATH when using
clang as the assembler. Finally this diff also changes the type of
optLevel from Int to Word, as we do not have negative optimization

Reviewers: erikd, hvr, austin, rwbarton, bgamari, kavon

Reviewed By: kavon

Subscribers: michalt, Ericson2314, ryantrinkle, dfeuer, carter, simonpj,
kavon, simonmar, thomie, erikd, snowleopard

Differential Revision:

nomeata raised a concern with this commit.Sep 6 2017, 6:34 PM
nomeata added a subscriber: nomeata.

The performance loss is not unrelated, according to It is a clear jump in this patch… would you mind having a second look what might have caused these?

This commit now has outstanding concerns.Sep 6 2017, 6:34 PM

I have an idea, will look into it later.

Observation one: delta of allocated bytes (@nomeata can this column be added to is pretty stable.

Benchmark namepreviouschangenowdelta

What this diff then does, is it drops the hardcoded module layout from the Ppr.hs and introduces the initLlvmTargets in the Systools.hs, which reads the llvm-targets file, to provide data-layout and opt/llc arguments per target, as well as allowing to specify new targets without having to recompile ghc.

initLlvmTargets is now called initGhcMonad in GHC.hs. I believe this is where this constant increase in allocations come from.

@bgamari sorry for now making that leap yesterday, when we were wondering where that allocation came from.

nomeata accepted this commit.Sep 7 2017, 4:05 AM
All concerns with this commit have now been addressed.Sep 7 2017, 4:05 AM