[llvm-dev] [RFC] Add IR level interprocedural outliner for code size.

Sanjoy Das via llvm-dev llvm-dev at lists.llvm.org
Wed Jul 26 12:07:16 PDT 2017


Hi,

On Wed, Jul 26, 2017 at 10:10 AM, Quentin Colombet via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> No, I mean in terms of enabling other optimizations in the pipeline like
> vectorizer. Outliner does not expose any of that.

I have not made a lot of effort to understand the full discussion here (so what
I say below may be off-base), but I think there are some cases where outlining
(especially working with function-attrs) can make optimization easier.

It can help transforms that duplicate code (like loop unrolling and inlining) be
more profitable -- I'm thinking of cases where unrolling/inlining would have to
duplicate a lot of code, but after outlining would require duplicating only a
few call instructions.


It can help EarlyCSE do things that require GVN today:

void foo() {
  ... complex computation that computes func()
  ... complex computation that computes func()
}

outlining=>

int func() { ... }

void foo() {
  int x = func();
  int y = func();
}

functionattrs=>

int func() readonly { ... }

void foo(int a, int b) {
  int x = func();
  int y = func();
}

earlycse=>

int func(int t) readnone { ... }

void foo(int a, int b) {
  int x = func(a);
  int y = x;
}

GVN will catch this, but EarlyCSE is (at least supposed to be!) cheaper.


Once we have an analysis that can prove that certain functions can't trap,
outlining can allow LICM etc. to speculate entire outlined regions out of loops.


Generally, I think outlining exposes information that certain regions of the
program are doing identical things.  We should expect to get some mileage out of
this information.

-- Sanjoy


More information about the llvm-dev mailing list