search for: pessimizations

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*

On Feb 20, 2013, at 8:40 AM, David Blaikie <dblaikie at gmail.com> wrote: > Sure, if you'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:

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

On Wed, Feb 20, 2013 at 12:39 PM, Chris Lattner <clattner at apple.com> wrote: > On Feb 20, 2013, at 8:40 AM, David Blaikie <dblaikie at gmail.com> wrote: > > Sure, if you'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)

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

LLVM (via clang) currently translates target intrinsics to generic IR whenever it can. For example, on x86 it translates _mm_loadu_pd to a simple load instruction with an alignment of 1. The backend is then responsible for translating the load back to the corresponding machine instruction. The advantage of this is that it opens up such code to LLVM's optimizers, which can theoretically speed

On Feb 20, 2013 8:32 AM, "Krzysztof Parzyszek" <kparzysz at codeaurora.org> wrote: > > 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

On Nov 14, 2011, at 3:01 PM, Dan Gohman wrote: > LLVM (via clang) currently translates target intrinsics to generic IR > whenever it can. For example, on x86 it translates _mm_loadu_pd to a > simple load instruction with an alignment of 1. The backend is then > responsible for translating the load back to the corresponding > machine instruction. > > The advantage of this is

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

OK - good to know. (not sure we're talking about pessimizing it - just not adding a new/possible optimization, to be clear) Just out of curiosity - are there particular reasons you prefer or need to ship an MSVC built version, rather than a bootstrapped Clang? On Mon, Nov 28, 2016 at 9:24 AM Robinson, Paul <paul.robinson at sony.com> wrote: > So I wouldn't personally worry too

Hello, This email picks up the thread that to my knowledge was last discussed here: http://lists.llvm.org/pipermail/llvm-dev/2015-July/088103.html In brief, infinite loops containing no side effects produce undefined behavior in C++ (and C in some cases), however in other languages, they have fully defined behavior. LLVM's optimizer currently assumes that infinite loops eventually terminate

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

...hand. > These were fixes I made two years ago. I'll have to do a giant diff > against the upstream LLVM. :) > > But yes, I fully intend to send these fixes up. Would it make sense to start something like a lib/Target/README-Vectors.txt file with a collection of small examples of pessimizations? We've successfully used text files like this to track "laundry lists" like this. High priority problems (e.g. the sorts that Duncan is pointing out) makes sense to track in bugzilla, of course. -Chris

...umber of p+=n ops, so when the IndVars pass rewrote all exit values, it added a lot of slightly different offsets to the main loop header that couldn't fit in the available registers which lead to unnecessary spills/reloads. I am wondering what is the usual strategy for dealing with such "pessimizations"? Is it possible to somehow modify the IndVarSimplify pass to take those issues into account (for example, tell it that adding offset computation + gep is potentially more expensive than simply reusing last var from the loop) or should it be recovered in some later pass? If so, is there an eas...

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