search for: pessimize

On Dec 27, 2011, at 5:09 AM, Jochen Wilhelmy wrote: > Hi! > > before InstCombine (llvm::createInstructionCombiningPass()) I have > a trunc from i8 to i1 and then a select: > > %45 = load i8* @myGlobal, align 1 > %tobool = trunc i8 %45 to i1 > %cond = select i1 %tobool, float 1.000000e+00, float -1.000000e+00 > > after instCombine I have: > > %29 = load i8*

...re willing to sacrifice the possible simplification of all indirect calls in any function that has even one nobuiltin requirement. > I don't understand what you mean by this. > 1) annotate calls > Pro: you can inline calls without pessimizing the function you inline into > Con: you pessimize all indirect calls in functions with at least one nobuiltin requirement > Can you give an example illustrating the con? I don't see how anything is pessimized with this approach. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm....

Hi! before InstCombine (llvm::createInstructionCombiningPass()) I have a trunc from i8 to i1 and then a select: %45 = load i8* @myGlobal, align 1 %tobool = trunc i8 %45 to i1 %cond = select i1 %tobool, float 1.000000e+00, float -1.000000e+00 after instCombine I have: %29 = load i8* @myGlobal, align 1 %30 = and i8 %29, 1 %tobool = icmp ne i8 %30, 0 %cond = select i1 %tobool, float 1.000000e+00,

>> Hi! >> >> before InstCombine (llvm::createInstructionCombiningPass()) I have >> a trunc from i8 to i1 and then a select: >> >> %45 = load i8* @myGlobal, align 1 >> %tobool = trunc i8 %45 to i1 >> %cond = select i1 %tobool, float 1.000000e+00, float -1.000000e+00 >> >> after instCombine I have: >> >> %29 = load i8*

I think Chris is saying that the and is necessary because with your i1 trunc you're ignoring all of the high bits. The and implements that. If you don't want this behavior, don't generate the trunc in the first place and just compare the full width to zero. Reid On Wed, Dec 28, 2011 at 6:45 AM, Jochen Wilhelmy <j.wilhelmy at arcor.de>wrote: > > >> Hi! >

> By the way i8 and trunc come from clang as clang represents a bool as i8  > in memory. of course it would > be a nice feature if I could tell clang to always use i1 for bool, this > would also remove the problem. > Is this possible? > > -Jochen #include <stdbool.h> ?

...g to sacrifice the possible simplification of all > indirect calls in any function that has even one nobuiltin requirement. > > I don't understand what you mean by this. > 1) annotate calls > Pro: you can inline calls without pessimizing the function you inline into > Con: you pessimize all indirect calls in functions with at least one > nobuiltin requirement > > Can you give an example illustrating the con? I don't see how anything is > pessimized with this approach. > Yep, sorry - seems I added more confusion to this thread rather than less. The only con I...

Am 29.12.2011 19:52, schrieb Reid Kleckner: > I think Chris is saying that the and is necessary because with your i1 > trunc you're ignoring all of the high bits. The and implements that. > If you don't want this behavior, don't generate the trunc in the > first place and just compare the full width to zero. But if a backend sees trunc from i8 to i1 it should know

...when intrinsics designed for the sole purpose of giving programmers access to specific machine instructions is translated to something other than those instructions. LLVM's optimizers aren't perfect, and there are many aspects of performance which they don't understand, so they can also pessimize code. If the user has gone through the trouble of using target-specific intrinsics to ask for a specific sequence of machine instructions, is it really appropriate for the compiler to emit different instructions, using its own heuristics? Dan

...of them restricted, the other one unrestricted. Sure, if you're willing to sacrifice the possible simplification of all indirect calls in any function that has even one nobuiltin requirement. 1) annotate calls Pro: you can inline calls without pessimizing the function you inline into Con: you pessimize all indirect calls in functions with at least one nobuiltin requirement 2) annotate functions Pro: you don't penalize indirect calls Con: you either penalize functions that are inlined into, or you avoid inlining. Now, surem , I would guess the number of indirect calls that end up being simpl...

...gned for the sole purpose of giving programmers access to specific > machine instructions is translated to something other than those > instructions. LLVM's optimizers aren't perfect, and there are many > aspects of performance which they don't understand, so they can also > pessimize code. > > If the user has gone through the trouble of using target-specific > intrinsics to ask for a specific sequence of machine instructions, > is it really appropriate for the compiler to emit different > instructions, using its own heuristics? There are several benefits to doi...

On 2/20/2013 10:19 AM, David Blaikie wrote: > > I'm still not understanding a few things in this thread, including one > here: if you annotate only the calls to print (say) then how do you > handle the indirect calls that the back end might yet optimize down to a > constant & then attempt to simplify? Would all indirect calls be > annotated with all the unsimplifiable

Hi all, The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64, which supports natively all types, but it is a real one for several embedded targets, with very few native types. I attached a patch to address this issue; if...

...stage 2 on Windows (building Clang > with MSVC build Clang) you do end up with a compiler with the desired > performance characteristics - then that's probably sufficient. > > > > Hold on there—we deliver an MSVC-built Clang to our licensees, and I would > really rather not pessimize it. > > --paulr > > > > *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *David > Blaikie via llvm-dev > *Sent:* Friday, November 25, 2016 8:52 AM > *To:* Mueller-Roemer, Johannes Sebastian; Malcolm Parsons; Hal Finkel; > llvm-dev at lists.llv...

...plementing Chandler's idea from the above thread, @llvm.sideeffect, a new intrinsic which is a no-op except that it tells the optimizer to behave as if there were side effects present: https://reviews.llvm.org/D38336 Similar results can be achieved with empty inline asms, however they tend to pessimize optimizations. The patch above allows all of the major optimizations to work in the presence of @llvm.sideeffect. One of the concerns raised is that front-ends would have to emit a lot of these intrinsics, potentially one in every loop, one in every function (due to opportunistic tail-call optimiz...

Peter Schuller wrote : > > I use it a lot, but I still get people mailing me > > .gifs and even worse .jpgs (of things like text!!!) > > That's okay let them. > > JPEG worse than GIF? What are you on? :) At least JPEG supports more than > 256 colors and you don't need to pay $100000 (or whatever) to write an > encoder... Uh, should I send you a GIF and

Someone hit a bug (not in bugs.llvm.org) caused by the non-Darwin call instructions not being marked as using the frame pointer. Is it safe to just add r11 / r7 as uses to the appropriate instructions like we do on Darwin? Does anyone care about the slight pessimization this would cause in the -fomit-frame-pointer case? Thanks, Cameron

On Feb 8, 2012, at 9:01 AM, David A. Greene wrote: > "Rotem, Nadav" <nadav.rotem at intel.com> writes: > >> Hi David! >> >> I'd be interested in hearing about the places that you had to fix. It >> seems like there is a number of people who are starting to look at the >> quality of the generated vector code. Maybe we should report our

Hello, Recently I've come across two instances where Induction Variable Simplification lead to noticable performance regressions. In one case, the removal of extra IV lead to the inability to reschedule instructions in a tight loop to reduce stalls. In that case, there were enough registers to spare, so using extra register for extra induction variable was preferable since it reduced

As far Am Mi., 18. März 2020 um 11:34 Uhr schrieb Chawla, Pankaj <pankaj.chawla at intel.com>: > >> There seems to be a bug in DI, see Felipe's answer. > Maybe I missed something. There seems to be no resolution to the problem. How can DA fix this without help from alias analysis? DependenceInfo is not using the AA interface correctly. Either DI has to be fixed, or another