Page MenuHomePhabricator

Please use GitHub pull requests for new patches. Avoid migrating existing patches. Phabricator shutdown timeline

[PM] Wire up optimization levels and default pipeline construction APIs in the PassBuilder.

Authored by chandlerc on Sep 12 2015, 2:05 AM.



These are really just stubs for now, but they give a nice API surface
that Clang or other tools can start learning about and enabling for

I've also wired up parsing various synthetic module pass names to
generate these set pipelines. This allows the pipelines to be combined
with other passes and have their order controlled, with clear separation
between the *kind* of canned pipeline, and the *level* of optimization
to be used within that canned pipeline.

The most interesting part of this patch is almost certainly the spec for
the different optimization levels. I don't think we can ever have hard
and fast rules that would make it easy to determine whether a particular
optimization makes sense at a particular level -- it will always be in
large part a judgement call. But hopefully this will outline the
expected rationale that should be used, and the direction that the
pipelines should be taken. Much of this was based on a long llvm-dev
discussion I started years ago to try and crystalize the intent behind
these pipelines, and now, at long long last I'm returning to the task of
actually writing it down somewhere that we can cite and try to be
consistent with.

Diff Detail


Event Timeline

chandlerc updated this revision to Diff 34621.Sep 12 2015, 2:05 AM
chandlerc retitled this revision from to [PM] Wire up optimization levels and default pipeline construction APIs in the PassBuilder..
chandlerc updated this object.
chandlerc added a subscriber: llvm-commits.
chandlerc updated this revision to Diff 34623.Sep 12 2015, 2:16 AM

Update with SROA now in the pipeline.

I appreciate the direction that O1 should not ruin the debugging experience.
One suggestion, and while I was in there anyway, pointed out some typos.

46 ↗(On Diff #34623)

I think "debuggability" (two g's) here and elsewhere.

56 ↗(On Diff #34623)

possibly -> possible

58 ↗(On Diff #34623)

Is it worth providing one or two examples of things _not_ to do at O1?
"For example, this level should avoid transforms that reorder statements, such as LICM."

65 ↗(On Diff #34623)

reduces -> increases (as in, makes it worse)

84 ↗(On Diff #34623)

if increase -> if it increases

hfinkel accepted this revision.Sep 22 2015, 2:42 PM
hfinkel added a reviewer: hfinkel.
hfinkel added a subscriber: hfinkel.

I suppose the idea is that opt -O3 will eventually be wired to be equivalent to -passes='default<O3>'?

Regardless, LGTM.

56 ↗(On Diff #34623)

efficient to execute code -> efficient-to-execute code

113 ↗(On Diff #34623)

slow but very small code -> slow, but very small, code

This revision is now accepted and ready to land.Sep 22 2015, 2:42 PM
chandlerc marked 7 inline comments as done.Feb 28 2016, 1:51 PM

Finally getting this landed. Thanks for the review, I've addressed all of the comments here.

Paul, please let me know if you don't like my examples. =]

This revision was automatically updated to reflect the committed changes.

Paul, please let me know if you don't like my examples. =]

The examples are fine; they're just examples, not a spec. Lacking a real "debugging experience" metric, exactly what's in O1 will surely evolve over time as we get actual user feedback. My snap reaction is to avoid code motion entirely but that's the spec from a previous job talking. I can see some being okay.