search for: gvnsink

Hi Danny, Thanks for that :) However I've just updated the prototype patch to NewGVN and it didn't need any API changes - all I rely on is GVNExpression. Hongbin, I wanted to explain a little about what GVNSink can currently do, what it was designed for and hopefully how to make it handle your testcase. *Background* Common code sinking is more difficult to efficently do than one might expect. Prior to October 2016, LLVM was able to handle simple cases of this within SimplifyCFG, for example: if (a)...

...identify that the stores correlate because the >> correlating stores appear in the same relative source order. In unswitch2() >> they have been permuted, and the algorithm cannot deal with this. This >> requires some kind of value numbering to do efficiently. >> >> The GVNSink pass that I really should get around to updating should solve >> this, eventually! >> >> James >> >> >> On Wed, 26 Apr 2017 at 08:19 Hongbin Zheng via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Looks like this do not work:...

...the add operation. > > This can be seen by simply removing the operand values used in the > calculations: > > %1 = add i32 , i32 > > %2 = add i32 , i32 > > > FWIW, you could use the core NewGVN structures (GVNExpression.h) to do this and just not fill in the operands. GVNSink does a variant of this by using them. In particular, the variant it does is: "do these instructions contribute to their uses in an equivalent way". This is the same problem, but if you weren't going to be willing to add any function arguments to fill in operand values. IE /// [ %a...

...dering and aliasing. In unswitch1(), it can identify that the stores correlate because the correlating stores appear in the same relative source order. In unswitch2() they have been permuted, and the algorithm cannot deal with this. This requires some kind of value numbering to do efficiently. The GVNSink pass that I really should get around to updating should solve this, eventually! James On Wed, 26 Apr 2017 at 08:19 Hongbin Zheng via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Looks like this do not work: > > // Type your code here, or load an example. > int a[10]; > &...

On 11 Sep 2017, at 21:32, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > As a data point for this, I did a quick walkthrough of the top-level of instcombine, and one thing that stuck out to me is that it tries to sink instructions in certain "easy" scenarios. That doesn't fit a graph rewriting system. The sinking in instcombine is not always a win. We

Thanks, Looks like inst combine do the job On Tue, Apr 25, 2017 at 9:36 PM, Davide Italiano <davide at freebsd.org> wrote: > On Tue, Apr 25, 2017 at 9:24 PM, Hongbin Zheng via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi, > > > > Is there a pass in LLVM that can optimize: > > > > if (x) > > a[i] = y0; > > else > >

Hey Everybody, A little while ago I posted an RFC( http://lists.llvm.org/pipermail/llvm-dev/2017-July/115666.html) with the proposition of adding a new outliner at the IR level. There was some confusion and many questions regarding the proposal which I’d like to address here: Note about nomenclature: Candidate: A repeated sequence of instructions within a module. Occurrence: One instance

> On Sep 27, 2017, at 3:23 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Sep 27, 2017 at 9:28 AM, Jessica Paquette via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> I think that, given previous discussion on the topic, we might want a split >> like this: >>