Page MenuHomePhabricator

Use CXX_FAST_TLS to enable shrink wrapping on PPC
Needs RevisionPublic

Authored by tjablin on Mar 7 2016, 4:46 PM.



This patch depends on both D17533 and D16984.

Shrink wrapping functions can improve performance for functions when the stack is unused. However, all functions where value live-ranges contain function calls are ineligible for shrink wrapping. Why?

  1. To avoid saving and restoring values across call-sites, LLVM allocates values with live-ranges that cross call sites to callee-saved registers
  1. If callee-saved registers are used, they must be saved (usually in the function prolog)
  1. ShrinkWrapping scans from the beginning of the function prolog to the first use of the stack. If a callee-saved register is saved to the stack in the function prolog, ShrinkWrapping will give up early.

To increase the applicability of ShrinkWrapping, this pass identifies instances where a live-range straddling a call-site prevents ShrinkWrapping. The pass switches the calling convention to CXX_FAST_TLS, that saves callee registers to virtual registers. This allows the backend to make better choices about where to save registers and in many cases avoids saving registers to the stack. The exit block is privatized for the fast and slow exit paths to allow each to be specialized independently.

Diff Detail

Event Timeline

tjablin updated this revision to Diff 50009.Mar 7 2016, 4:46 PM
tjablin retitled this revision from to Use CXX_FAST_TLS to enable shrink wrapping on PPC.
tjablin updated this object.
tjablin added reviewers: hfinkel, kbarton, cycheng.
tjablin added a subscriber: llvm-commits.
tjablin updated this revision to Diff 50093.Mar 8 2016, 5:20 PM

Switch from a ModulePass to a FunctionPass since outlining is no longer performed.

cycheng added inline comments.Mar 13 2016, 8:26 PM

Since the patch aims for creating more shrink-wrapping chances, maybe we could use more appropriate names?


use std::any_of ?


This do affect sibling call optimization, because callee and caller should have same calling convention, so SCO have to handle this case.


It would be better if we could have test cases for llc, because we would like to see how this change final code gen

kbarton requested changes to this revision.Apr 4 2016, 12:53 PM
kbarton edited edge metadata.

A couple general comments:

  1. Can we add statistics to collect the number of times we've made changes? I think this would be useful to understand how effective this is.
  2. In general, I think we should prefer references to pointers unless there is a chance the parameter can be null. I think most of the cases here could be references. If they need to stay as pointers, please make sure we check that they are valid before using them.
  3. We should also mark the parameters as const whenever they are not expected to change. I believe that is true for many of the methods here, as they are just checking for a property and then returning true/false.

These could both be reference parameters, instead of pointers.
Can they be made const as well?


Could this be a reference instead of a pointer?


Can F be const?


Can BB be const?

This revision now requires changes to proceed.Apr 4 2016, 12:53 PM