search for: unswitch1

Hi, Yes, I can see 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...

...<james at jamesmolloy.co.uk> > wrote: > >> Hi, >> >> Yes, I can see 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. >> &g...

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

...>>> Hi, >>>> >>>> Yes, I can see 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...