Clean up opt and llc

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

Description

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
levels.

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

Reviewed By: kavon

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

Differential Revision: https://phabricator.haskell.org/D3352

Details

Auditors
nomeata
Committed
bgamariSep 6 2017, 10:33 AM
Reviewer
kavon
Differential Revision
D3352: Clean up opt and llc
Parents
rGHC0cd467b22695: rts: Fix use of #if
Branches
Unknown
Tags
Unknown
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 https://perf.haskell.org/ghc/#revision/22733532171330136d87533d523f565f2a4f102f. 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 perf.haskell.org?) is pretty stable.

Benchmark namepreviouschangenowdelta
tests/alloc/Naperian487978800.0516513169122519032bytes
tests/alloc/T10547344635440.0731369826882519144bytes
tests/alloc/T12150727330880.0346752527362519648bytes
tests/alloc/T12234795952400.0315821023442507104bytes
tests/alloc/T5837523762640.0481548957522519488bytes

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