[PATCH] D47816: [InstCombine] Stop sinking instructions across function call.

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a comment.

In https://reviews.llvm.org/D47816#1136433, @renlin wrote:

> In https://reviews.llvm.org/D47816#1136432, @lebedev.ri wrote:
>
> > In https://reviews.llvm.org/D47816#1136426, @renlin wrote:
> >
> > > In https://reviews.llvm.org/D47816#1136346, @lebedev.ri wrote:
> > >
> > > > I'm seeing `what`, but not `why`.
> > > >  What is the motivation behind this change?
> > > >  What problem is it trying to solve?
> > >
> > >
> > > In one of the test case I have, the sinking of a load instruction (together with the operands used) across a inlined function increases the number of instructions generated.
> >
> >
> > Instructions as in IR instructions? Or the instructions in the final assembly?
>
>
> Final machine assembly.


Perhaps you can add an example test?
There seems to be some precedent for that:

  llvm/test/CodeGen/X86$ grep -r instcombine | grep RUN
  2009-03-23-i80-fp80.ll:; RUN: opt < %s -instcombine -S | grep 302245289961712575840256
  2009-03-23-i80-fp80.ll:; RUN: opt < %s -instcombine -S | grep K40018000000000000000
  vec_udiv_to_shift.ll:; RUN: opt < %s -instcombine -S | FileCheck %s
  vec_ins_extract.ll:; RUN: opt < %s -sroa -instcombine | \
  no-plt-libcalls.ll:; RUN: opt < %s -instcombine -S | FileCheck %s

But i must say, right now this sounds the problem is elsewhere,
and this change only papers over it, by pessimizing all other cases.


https://reviews.llvm.org/D47816