Displaying 20 results from an estimated 267 matches for "pessim".
Did you mean:
possim
2011 Dec 28
0
[LLVMdev] InstCombine "pessimizes" trunc i8 to i1?
...this a bug or intended? My version is 3.0 release.
> Please tell me where I can remove this rule even if it is intended for
> mainline.
This is intentional: an 'and' must be done in both cases, so this transformation is exposing it to the optimizer.
Why do you consider this to be a pessimization? Does one produce inferior machine code?
-Chris
2013 Feb 20
2
[LLVMdev] [RFC] NoBuiltin Attribute
...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: 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 H...
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?
...ed? My version is 3.0 release.
>> Please tell me where I can remove this rule even if it is intended for
>> mainline.
> This is intentional: an 'and' must be done in both cases, so this transformation is exposing it to the optimizer.
>
> Why do you consider this to be a pessimization? Does one produce inferior machine code?
I consider it a pessimization as it is one additional instruction and
I'm mainly interested in target
independent optimizations because I regenerate highlevel code from it
("Exporting 3D scenes from Maya to WebGL using clang and llvm"...
2011 Dec 29
0
[LLVMdev] InstCombine "pessimizes" trunc i8 to i1?
...> >> Please tell me where I can remove this rule even if it is intended for
> >> mainline.
> > This is intentional: an 'and' must be done in both cases, so this
> transformation is exposing it to the optimizer.
> >
> > Why do you consider this to be a pessimization? Does one produce
> inferior machine code?
>
> I consider it a pessimization as it is one additional instruction and
> I'm mainly interested in target
> independent optimizations because I regenerate highlevel code from it
> ("Exporting 3D scenes from Maya to WebG...
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
...ail.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: 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...
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
...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
2013 Feb 20
0
[LLVMdev] [RFC] NoBuiltin Attribute
...ith two calls to printf in the
same function, one 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...
2011 Nov 14
0
[LLVMdev] Target intrinsics and translation
...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...
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 address this issue;...
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:
>...
2017 Oct 27
3
Infinite loops with no side effects
...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 opti...
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.
...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
2019 Aug 08
3
How to best deal with undesirable Induction Variable Simplification?
...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 ther...
2020 Mar 18
2
valid BasicAA behavior?
...aliasPHI looks for any incoming value contradicting the NoAlias assumption, it would be equivalant to always return MayAlias.
> I pasted the code snippet below with some extra comments.
As far as the AA interface specification is concerned, the NoAlias
result is correct. Such a patch would be a pessimization without
giving any additional guarantees.
Michael