search for: pessimal

Displaying 20 results from an estimated 267 matches for "pessimal".

Did you mean: fpessimal
2011 Dec 28
0
[LLVMdev] InstCombine "pessimizes" trunc i8 to i1?
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*
2013 Feb 20
2
[LLVMdev] [RFC] NoBuiltin Attribute
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:
2011 Dec 27
2
[LLVMdev] InstCombine "pessimizes" trunc i8 to i1?
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,
2011 Dec 28
3
[LLVMdev] InstCombine "pessimizes" trunc i8 to i1?
>> 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*
2011 Dec 29
0
[LLVMdev] InstCombine "pessimizes" trunc i8 to i1?
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! >
2011 Dec 30
0
[LLVMdev] InstCombine "pessimizes" trunc i8 to i1?
> 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> ?
2013 Feb 20
0
[LLVMdev] [RFC] NoBuiltin Attribute
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)
2011 Dec 30
3
[LLVMdev] InstCombine "pessimizes" trunc i8 to i1?
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
2011 Nov 14
3
[LLVMdev] Target intrinsics and translation
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
2013 Feb 20
0
[LLVMdev] [RFC] NoBuiltin Attribute
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
2011 Nov 14
0
[LLVMdev] Target intrinsics and translation
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
2013 Feb 20
3
[LLVMdev] [RFC] NoBuiltin Attribute
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
2011 Mar 13
7
[LLVMdev] IndVarSimplify too aggressive ?
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
2016 Nov 28
5
RFC: Constructing StringRefs at compile time
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
2017 Oct 27
3
Infinite loops with no side effects
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
2001 Jun 29
3
Pessimism
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
2011 Jun 26
2
[LLVMdev] ARM instructions clobbering frame pointer
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
2012 Feb 08
2
[LLVMdev] SelectionDAG scalarizes vector operations.
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
2019 Aug 08
3
How to best deal with undesirable Induction Variable Simplification?
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
2020 Mar 18
2
valid BasicAA behavior?
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