This is an archive of the discontinued LLVM Phabricator instance.

[DwarfEHPrepare] Don't prune unreachable resumes at optnone
ClosedPublic

Authored by nikic on May 21 2020, 12:38 PM.

Details

Summary

Disable pruning of unreachable resumes in the DwarfEHPrepare pass at optnone. While I expect the pruning itself to be essentially free, this does require a dominator tree calculation, that is not used for anything else. Saving this DT construction makes for a a 0.4% O0 compile-time improvement.

Diff Detail

Event Timeline

nikic created this revision.May 21 2020, 12:38 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 21 2020, 12:38 PM
rnk added a subscriber: compnerd.May 21 2020, 2:01 PM

Neat

include/llvm/CodeGen/Passes.h
343 ↗(On Diff #265578)

IMO it makes more sense to pass in the optimization level, and then let the pass decide what that means it should do, so the caller doesn't have to think as much about the meaning of this parameter. It will simplify the call site as well.

lib/CodeGen/DwarfEHPrepare.cpp
150 ↗(On Diff #265578)

I think it makes more sense to check this at the caller side.

test/CodeGen/X86/O0-pipeline.ll
30 ↗(On Diff #265578)

As a separate issue, this module pass between all the function passes is probably bad for cache locality. My understanding is that it acts as a barrier. We'll get these loops:

for all functions:
  for some passes:
    run fn passes
run rewrite symbol pass
for all functions
  for remaining passes:
    run fn pass

Instead of this loop:

for all functions:
  for all fn passes:
    run fn pass

I bet we can make createRewriteSymbolsPass return null if the YAML file option is not set, and then remove this from the standard pipeline.

@compnerd

nikic updated this revision to Diff 265795.May 22 2020, 1:23 PM

Pass OptLevel instead of bool, move check.

nikic marked 4 inline comments as done.May 22 2020, 1:27 PM
nikic added inline comments.
include/llvm/CodeGen/Passes.h
343 ↗(On Diff #265578)

I was a bit on the fence about this one, as "optimization level" seems like a higher-level concept to make, that should be managed by the pipeline builder, not individual passes. But it looks like all machine passes get passed the optimization level implicitly, so probably this view doesn't really match reality where the backend is concerned.

test/CodeGen/X86/O0-pipeline.ll
30 ↗(On Diff #265578)

Good point. I might look into it if no one beats me to it...

rnk accepted this revision.May 23 2020, 8:59 AM

lgtm, thanks

This revision is now accepted and ready to land.May 23 2020, 8:59 AM

typo in the description: a a

This revision was automatically updated to reflect the committed changes.
nikic marked an inline comment as done.