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

[vivek pandya via llvm-dev]

On Tue, Jun 21, 2016 at 1:45 AM, Matthias Braun <matze at braunis.de> wrote:

>
> > 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.
>
> Yes at -O3 level simple indirect calls including virtual functions are
getting optimized to direct call.


> 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);
> }
>

I tried this case and my simple hack fails to optimize it :-) . This
requires discussion on IRC.

Sincerely,
-Vivek


> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160621/386d09b3/attachment.html>