Opened 4 years ago

Last modified 9 months ago

#11295 new task

Figure out what LLVM passes are fruitful

Reported by: bgamari Owned by: kavon
Priority: normal Milestone: 8.10.1
Component: Compiler (LLVM) Version: 7.10.3
Keywords: Cc: angerman, michalt, kavon
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: #14528 Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by angerman)

Builds using GHC's LLVM backend are currently substantially slower than GHC's own native code generator. There are a few possible reasons for this,

  1. the cost of forking processes and serializing/parsing LLVM's intermediate representation
  2. the cost of the more powerful optimizations responsible for LLVM's (hopefully) better code generation
  3. the cost of redundant optimizations overlapping effort already expended by GHC

Given that some architecture (e.g. ARM) are only supported by LLVM and therefore suffer considerably at the hand of our slow builds, we should try to reduce 3.

Change History (23)

comment:1 Changed 4 years ago by bgamari

Owner: set to bgamari

comment:2 Changed 4 years ago by bgamari

Description: modified (diff)

comment:3 Changed 3 years ago by angerman

Description: modified (diff)

comment:4 Changed 3 years ago by angerman

Cc: angerman added

comment:5 Changed 3 years ago by bgamari

Owner: bgamari deleted

I'm afraid this is something that I won't have time to take up in the near future.

comment:6 Changed 3 years ago by michalt

Cc: michalt added

comment:7 Changed 2 years ago by bgamari

Cc: kavon added

Kavon, I noticed you mentioned evaluating which LLVM optimizations passes are worthwhile in ticket:10074#comment:25. This is the ticket I created a while back to track this. Feel free to leave notes here when you end up picking this up.

comment:8 Changed 2 years ago by bgamari

One useful tool for this may be OpenTuner, which is mentioned in this talk in the context of tuning optimization pass sequences.

comment:9 Changed 2 years ago by kavon

Owner: set to kavon

I'll try to get a conservative tuning into 8.4.1

comment:10 Changed 2 years ago by kavon

Actually I'm now using OpenTune, repo with the bootstrap code forthcoming.

comment:11 Changed 2 years ago by kavon

FYI the repo with progress on this front is here: https://github.com/kavon/autotune

A good pass sequence that is not overfit to a specific program is more likely to be ready for 8.6.x

comment:12 Changed 2 years ago by bgamari

Yay! Thanks kavon.

comment:13 Changed 23 months ago by bgamari

Any progress on a tuning for 8.4, Kavon? Thanks again for looking at this.

comment:14 Changed 22 months ago by kavon

Ben, I think the autotuner is now ready to be applied to Haskell programs: it can successfully tune C/C++ programs, with or without running the output program, to match -O3 in a reasonable time.

If it's not too late, I can try to get something in for 8.4. My plan is to pick a few "representative" programs[*], tune on each one individually, and see which pass ordering does the best across nofib. If one of them does better than the -Ox passes, we could drop it in GHC pretty easily.

What do you think?

[*] Suggestions are welcome here. Infrastructure to tune against the "average" of several programs (using a special objective function) would be ideal, but that infrastructure is not ready yet.

Last edited 22 months ago by kavon (previous) (diff)

comment:15 Changed 22 months ago by bgamari

What do you think?

Sounds good to me. Looking forward to it.

comment:16 Changed 22 months ago by kavon

Blocked By: 14528 added

comment:17 Changed 16 months ago by bgamari

kavon, any progress on this? It would be great to have something for 8.6.

comment:18 Changed 16 months ago by kavon

Milestone: 8.6.1

I'll definitely get something in for 8.6, whether auto-generated or hand-crafted. I've had some good hand-crafted pass sequences sitting around for a while now.

Progress on the autotuner has stalled because (1) it finds weird bugs in LLVM sometimes, and I should just fix them instead of trying to avoid them, (2) I'll be working with some people this summer to create a proper autotuner for LLVM, so we can hopefully use that instead of what I hacked together.

comment:19 Changed 16 months ago by Ben Gamari <ben@…>

In a4ae199/ghc:

Extract hard-coded LLVM opt flags into a file

To resolve ticket #11295, I think it makes sense to stop hard-coding
the pass sequences used by GHC when compiling with LLVM into the
compiler
itself.

This patchset introduces a companion to the existing `llvm-targets` file
called `llvm-passes`. The passes file is a simple association list that
holds the default LLVM `opt` pass sequence used by GHC. This allows end
users to easily save their favorite optimization flags when compiling
with LLVM.

The main benefit for ticket #11295 is that when adding a custom pass
sequence, it tends to be an extremely long string that would be
unsightly in the code.

This is essentially part 1 of 2 for ticket #11295.

Test Plan: ./validate

Reviewers: bgamari, angerman

Reviewed By: angerman

Subscribers: rwbarton, thomie, carter

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

comment:20 Changed 14 months ago by bgamari

Any word on this?

comment:21 Changed 14 months ago by bgamari

Milestone: 8.6.18.8.1

These won't be fixed for in GHC 8.6.

comment:22 Changed 12 months ago by bgamari

kavon, it would be great to have this done for 8.8. Do let me know if there's any way I can help.

comment:23 Changed 9 months ago by osa1

Milestone: 8.8.18.10.1

Bumping milestones of low-priority tickets.

Note: See TracTickets for help on using tickets.