search for: instcombin

Hello, this mail is to raise awareness of https://reviews.llvm.org/D81728, which is substantial enough of a conceptual change that it should probably at least be mentioned in llvm-dev. InstCombine has dealt with target-specific intrinsics for a long time, since its fix-point iteration is arguably the right place to do so. A downside is that there's a pull to add an increasing amount of code into lib/Transforms/InstCombine/ that really is target-specific. What the aforementioned change...

...e basic block from what I can tell by the code >> here. >> > >> > I think this means that this pass explicitly defers handling simple >> cases >> > like: >> > https://reviews.llvm.org/D33342 >> > ...to another pass, and currently that pass is InstCombine (because the >> > patterns really can't be any simpler than the tests in that patch, >> right?). >> > >> > I think that improving compile-time should not preclude improving >> > InstCombine. We should do both. >> > >> >> Just thoug...

I’m taking a first look at InstCombine performance. I picked up the caching patch and ran a few experiments on one of our larger C++ apps. The size of the *.0.2.internalize.bc no-debug IR is ~ 30M. Here are my observations so far. Interestingly, caching produced a slight but measurable performance degradation of -O3 compile time. Ins...

> On Apr 13, 2017, at 7:43 PM, Davide Italiano <davide at freebsd.org> wrote: > > On Thu, Apr 13, 2017 at 5:18 PM, Mikulin, Dmitry > <dmitry.mikulin at sony.com> wrote: >> I’m taking a first look at InstCombine performance. I picked up the caching patch and ran a few experiments on one of our larger C++ apps. The size of the *.0.2.internalize.bc no-debug IR is ~ 30M. Here are my observations so far. >> >> Interestingly, caching produced a slight but measurable performance degradation of -O3...

> If we don't care about trying to optimize out overflow checks in > InstCombine, I'd go with moving the complexity to CGP. I think instcombine should optimize out overflow checks (as it does today) without introducing _with_overflow calls. Are there reasons why such an approach would not work? > However, I think > InstCombine is doing the right thing here by form...

...t;>> pipeline? I'm inclined to think this is mostly an additive effect >>> adding matchers here and there that don't really hurt small testcases >>> but we pay the debt over time (in particular for LTO). Side note, I >>> noticed (and others did as well) that instcombine is way slower with >>> `-g` on (one of the reasons could be we walking much longer use lists, >>> due to the dbg use). Do you have numbers of instcombine ran on IR with >>> and without debug info? >> >> I do have the numbers for the same app with and without...

Just thinking out loud…. I’m really not familiar with the vast majority of what instcombine does, so please excuse me if my naiveté is too obvious. I can’t help but notice all of the uses of ‘and’ in Daniel B’s description of what instcombine is right now: > On Sep 8, 2017, at 11:27 PM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > FWIW, Before getti...

Hi All, I finally got around to cleaning up my proposal to merge `SimplifyLibCalls` into `InstCombiner`. There is still an open question or two and I am sure there are parts that could be better specified, but this is good enough to discuss. Feedback is most welcome. Abstract ======== This proposal is an attack plan for PR11895 [1]. Currently within LLVM we have two passes that are used to fo...

On 10 August 2013 15:32, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi Jakob, > > Thanks for creating this interesting proposal. > Let me just comment on this part: > > >>> What might be better is to put some abstract interface between >>> instcombine and the IR, so that instcombine can be run on these pseudo-MIs >>> as well as on IR. >> >> >> I like the idea of sharing code between IR and MI passes through an >> abstract interface. I think that later stages in the IR pipeline also need >> an instruction o...

...Silva via llvm-dev wrote: > > > On Mon, Sep 11, 2017 at 8:14 AM, Daniel Neilson via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > Just thinking out loud…. I’m really not familiar with the vast > majority of what instcombine does, so please excuse me if my > naiveté is too obvious. I can’t help but notice all of the uses of > ‘and’ in Daniel B’s description of what instcombine is right now: > > > On Sep 8, 2017, at 11:27 PM, Daniel Berlin via llvm-dev > <llvm-dev at lists.llvm.org...

...>>>>>>>> If >>>>>>>> ​we will >>>>>>>> move >>>>>>>> ​reassociation, >>>>>>>> or keep additional ones >>>>>>>> ​,​ >>>>>>>> out of instcombine, >>>>>>>> ​open questions for me would be >>>>>>>> ​​: >>>>>>>> >>>>>>>> >>>>>>>> 1. Since -reassociate isn't a fixed point pass, >>>>>>>> >>&gt...

On Mon, Jan 5, 2015 at 1:40 AM, Pete Cooper <peter_cooper at apple.com> wrote: > Hi lx, Philip > > I've seen an instcombine which helps with this situation. It fires when > the function types on both sides of the bitcast have the same number of > operands and compatible types. It then adds bitcasts on the arguments and > removes the one on the called function. > It indeed does, InstCombiner::transformConst...

Thanks a lot for the clarification! So if my input .ll is not expected to contain any of the above mentioned weird corner cases, but, after -instcombine, ends up containing "undef" values, then it must be that the input .ll has bugs unknown to me, right? Best Regards, Paul On Wed, Jun 11, 2014 at 3:09 PM, Nick Lewycky <nlewycky at google.com> wrote: > On 11 June 2014 12:26, Paul Vario <paul.paul.mit at gmail.com> wrote...

InstCombine says in its getAnalysisUsage that it preserves the CFG, but for the 4th argument in its INITIALIZE_PASS call, it says false, which I believe corresponds to whether it preserves the CFG. Is this a mistake, or is there deeper meaning here? InstructionCombining.cpp:73-82 char InstCombiner::ID = 0;...

...y not? If it can handle those easily, I'll abandon D45842. Also, I don't know if it's better to include that functionality as another iteration of the existing -reassociate or split it off as its own pass. But I think it should do the distributive simplifications that are currently in -instcombine (InstCombiner::SimplifyUsingDistributiveLaws). Using that instsimplify logic for analysis lets us decide if the reassociation is worthwhile in the 1st place, it removes the risk that some other pass would somehow mess up the pattern before instcombine could zap it, and it reduces the burden on ins...

...79 = fadd <4 x float> %t75, %t78 %t80 = shufflevector <4 x float> %t50, <4 x float> undef, <4 x i32> <i32 3, i32 3, i32 3, i32 3> %t82 = fmul <4 x float> %t67, %t80 %t83 = fadd <4 x float> %t79, %t82 ret <4 x float> %t83 } Before D70246, opt -instcombine gives this: define <4 x float> @f(i32 %t32, <4 x float>* %t24) { .entry: %t43 = insertelement <3 x i32> undef, i32 %t32, i32 2 %t44 = bitcast <3 x i32> %t43 to <3 x float> %t55 = load <4 x float>, <4 x float>* %t24, align 16 %t58 = getelementptr &...

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 hit a case recently where instcombine made a hot loop in a benchmark significantly sl...

Hi Jakob, Thanks for creating this interesting proposal. Let me just comment on this part: >> What might be better is to put some abstract interface between >> instcombine and the IR, so that instcombine can be run on these >> pseudo-MIs as well as on IR. > > I like the idea of sharing code between IR and MI passes through an > abstract interface. I think that later stages in the IR pipeline also need > an instruction optimizer instead of a cano...

...gt;>>>>>> >>>>>>> If >>>>>>> ​we will >>>>>>> move >>>>>>> ​reassociation, >>>>>>> or keep additional ones >>>>>>> ​,​ >>>>>>> out of instcombine, >>>>>>> ​open questions for me would be >>>>>>> ​​: >>>>>>> >>>>>>> >>>>>>> 1. Since -reassociate isn't a fixed point pass, >>>>>>> >>>>>> >>&g...

Hi Fellows, If a .ll file contains no "undef"'s, does it necessarily mean that every value is properly initialized before use in the IR? What confuses me is that I notice that -instcombine can introduce "undef" to the previously undef-clean .ll file ... is it always safe to use -instcombine as one of the preprocessing pass? Thanks. Best, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attac...