search for: unswitch2

...e why that would not work. The sinking algorithm in SimplifyCFG isn't particularly clever. In particular it can't reason about memory ordering 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-d...

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 > >

...The sinking algorithm in SimplifyCFG isn't particularly clever. In >> particular it can't reason about memory ordering 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 >>...

...n SimplifyCFG isn't particularly clever. In >>>> particular it can't reason about memory ordering 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, even...