-
Notifications
You must be signed in to change notification settings - Fork 201
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
compiler: tune the LLVM optimizer pipeline (fixes #315).
whitequark
committed
Mar 26, 2016
1 parent
3ee9834
commit f5c720c
Showing
1 changed file
with
19 additions
and
12 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
f5c720c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A comment from the sidelines: If I'm not mistaken (I'm not familiar with the Python API), this chooses a very small, fixed set of passes? In particular, there is no LLVM-level inlining? It is true that the defaults given by PassManagerBuilder are tuned for IR similar to that produced similar to the Clang frontend (and thus manually choosing a set of passes can yield quite some benefits both in terms of compile- and runtime), but do expect having to adapt the pipeline when switching between LLVM releases.
f5c720c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@klickverbot Sure. Since compile times are a problem for us, I only enabled the passes that provide direct benefit. Thus, inlining is not enabled yet because method calls are emitted via a form of indirection that prevents LLVM from statically determining the callee. Once that's taken care of, I'll add inlining with an appropriate threshold, as well as LICM, IPSCCP and probably a few others, whose impact I currently cannot measure.
f5c720c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyway, we're stuck on LLVM 3.5, since I don't think anyone is porting the OR1K backend to more recent LLVM, so whatever problems may arise during migration to more recent LLVM are immaterial in foreseeable future.
f5c720c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, thanks – I just happened to see the commit and wanted to make sure you are aware of the possible issues since I've been bitten by release-to-release changes in the past. I'm not sure how good the ARTIQ codegen is (just starting to play around with it), but in tight code (think C/C++/D/Rust/…), changes in the assumptions made by various passes on the "level of canonicalization" of their input IR due to changes in the "expected" pass pipeline are are definitely noticeable.
f5c720c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, definitely. But the default pipeline produces results that are very bad, because ARTIQ's codegen is designed with running SROA as the very first step, to break the aggregates containing local variables (which are necessary to faithfully support closures).
f5c720c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@klickverbot I adjusted pipeline to a more realistic state in 20ad762.