[llvm-dev] [GSoC 2016] [Weekly Status] Interprocedural Register Allocation

[Matthias Braun via llvm-dev]

> On Jun 20, 2016, at 12:53 PM, Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi Vivek,
> 
> vivek pandya via llvm-dev wrote:
> >     int foo() {
> >     return 12;
> >     }
> >
> >     int bar(int a) {
> >     return foo() + a;
> >     }
> >
> >     int (*fp)() = 0;
> >     int (*fp1)(int) = 0;
> >
> >     int main() {
> >     fp = foo;
> >     fp();
> >     fp1 = bar;
> >     fp1(15);
> >     return 0;
> >     }
> 
> IMO it is waste of time trying to do a better job at the IPRA level on
> IR like the above ^.  LLVM should be folding the indirect calls to
> direct calls at the IR level, and if it isn't that's a bug in the IR
> level optimizer.
+1 from me.

The interesting cases are the non-obvious ones (assumeing foo/bar have the same parameters). Things gets interesting once you have uncertainty in the mix. The minimally interesting case would look like this:

int main() {
    int (*fp)();
    if (rand()) {
        fp = foo;
    } else {
        fp = bar;
    }
    fp(42);
}

However predicting the possible targets of a call is IMO a question of computing a call graph datastructure and improving upon that. We should be sure that we discuss and implement this independently of the register allocation work!

- Matthias