search for: microoptim

On Aug 18, 2010, at 10:27 AM, Bob Wilson wrote: >> I tend to think that it isn't worth the compile time to try to microoptimize out every compare, but I could be convinced otherwise if there are important use cases we're failing to handle. I also do think that whole-function selection dags will solve a lot of grossness (e.g. much of codegen prepare) with a very clean model. > > I'll take a look at Machine...

...rtially redundant cases, then machine sink is missing something. If you're seeing reextends of already extended values, then it sounds like the heuristic to track that the live-out vreg is extended isn't working. > > I tend to think that it isn't worth the compile time to try to microoptimize out every compare, but I could be convinced otherwise if there are important use cases we're failing to handle. I also do think that whole-function selection dags will solve a lot of grossness (e.g. much of codegen prepare) with a very clean model. I'll take a look at Machine CSE and M...

...s to function types is not all that frequent so I wouldn't expect Note that every LLVM function involves creating a pointer to function, so it might be a good idea to implicitly encode pointers for every function type (there is no other way to use a function type in any case). If you guys are microoptimizing the bc format, this is an idea. *shrug* -Chris -- http://llvm.org/ http://nondot.org/sabre/

The pointer could only be null if the length is zero. If the length is zero, you shouldn't be loading it. Defaulting to null instead of "" is also a microoptimization. -Chris > On Sep 25, 2016, at 10:49 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Sep 25, 2016, at 9:10 AM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> While porting LLDB over to StringRef, I a...

...seeing partially redundant cases, then machine sink is missing something. If you're seeing reextends of already extended values, then it sounds like the heuristic to track that the live-out vreg is extended isn't working. I tend to think that it isn't worth the compile time to try to microoptimize out every compare, but I could be convinced otherwise if there are important use cases we're failing to handle. I also do think that whole-function selection dags will solve a lot of grossness (e.g. much of codegen prepare) with a very clean model. -Chris

I'm looking at llvm-generated ARM code that has some unnecessary UXTB (zero extend) instructions, and it seems to me that doing type legalization as an entirely local transformation is not the best approach. I'm thinking in particular about legalizing integer types that need to be promoted to the target register size, i.e., i8 and i16 for ARM promoting to i32. Currently we sign-extend or

On Dec 27, 2007, at 9:14 AM, Jack Howarth wrote: > Anton, > Doh! It appears that *-*-darwin* is preset in configure to > not build libgfortran... Ah, that should certainly be fixed. Please send in the obvious patch to the llvm-commits list (after verifying that it doesn't break the c/c ++/objc build), thanks Jack! > I'll try removing libgfortran from noconfigdirs.

I’ve got some new patches and some numbers. The patches are all the changes required to strip intrinsics using the preprocessor defines I showed in my earlier patches. It actually isn’t that much change to LLVM. Clang will need similar changes too. There were only 9 files that referenced target intrinsics outside the corresponding target. These patches are still WIP, and there is some nastiness,

Anton, Doh! It appears that *-*-darwin* is preset in configure to not build libgfortran... # APPLE LOCAL end ARM darwin target powerpc-*-darwin* | i[3456789]86-*-darwin*) noconfigdirs="$noconfigdirs bfd binutils ld gas opcodes gdb gprof" noconfigdirs="$noconfigdirs sim target-rda" # LLVM LOCAL begin noconfigdirs="$noconfigdirs target-boehm-gc

On Jan 7, 2011, at 11:25 AM, Dale Johannesen wrote: > We might want to make physical registers negative and virtuals positive, or vice versa. Then FirstVirtualRegister is 0 or 1, and we could get rid of those annoying subtractions of FirstVirtualRegister all over the virtual-register-handling passes. Since 0 is used all over the place as "invalid register" it is probably best to

On Mon, 2004-08-23 at 19:46, Robert Mykland wrote: > At 06:43 PM 8/20/2004, Chris Lattner wrote: > >I don't understand what you're getting at here. You can change char to > >default to unsigned right now with llvm-gcc -funsigned-char. I don't > >understand how that would change anything to be more useful though. > > Well, in the old days, char strings were

Returning to an old discussion here.... On Aug 18, 2010, at 10:42 AM, Chris Lattner wrote: > On Aug 18, 2010, at 10:27 AM, Bob Wilson wrote: >>> I tend to think that it isn't worth the compile time to try to microoptimize out every compare, but I could be convinced otherwise if there are important use cases we're failing to handle. I also do think that whole-function selection dags will solve a lot of grossness (e.g. much of codegen prepare) with a very clean model. >> >> I'll take a look at...

On Mon, Nov 11, 2013 at 11:29 PM, Chris Lattner <clattner at apple.com> wrote: > Hi Manman (and llvmdev), > > I filed these two bugs to track the ideas that I was cooking: > > http://llvm.org/bugs/show_bug.cgi?id=17891 > http://llvm.org/bugs/show_bug.cgi?id=17892 > > TL;DR: I'm saying we should go from: > > !14 = metadata !{i32 786445, metadata !1,

Hi Manman (and llvmdev), I filed these two bugs to track the ideas that I was cooking: http://llvm.org/bugs/show_bug.cgi?id=17891 http://llvm.org/bugs/show_bug.cgi?id=17892 TL;DR: I'm saying we should go from: !14 = metadata !{i32 786445, metadata !1, metadata !10, metadata !"y", i32 3, i64 32, i64 32, i64 32, i32 0, metadata !13} to: !14 = metadata

.... > > First, there are two things going on here: removing an indirection through a referenced metadata node and flattening N values into a string inclusion. Removing the indirection seems obvious strict goodness, my comments are about the second part. David pointed out that the PR17892 is a microoptimization that may not even be worthwhile. I think that the flattening into a string is the important part. > I'm moderately opposed to just encoding these in a string format. I think we can do something substantially better both for space, time, and readability. Fundamentally, there is no re...

I resurrected these patches after prompting from Andy Lutomirski's recent patches. I put them on the back-burner because vring_bench had a 15% slowdown on my laptop: pktgen testing revealed a speedup, if anything, so I've cleaned them up. Rusty Russell (3): virtio_net: pass well-formed sgs to virtqueue_add_*() virtio_ring: assume sgs are always well-formed. virtio_ring: unify

I resurrected these patches after prompting from Andy Lutomirski's recent patches. I put them on the back-burner because vring_bench had a 15% slowdown on my laptop: pktgen testing revealed a speedup, if anything, so I've cleaned them up. Rusty Russell (3): virtio_net: pass well-formed sgs to virtqueue_add_*() virtio_ring: assume sgs are always well-formed. virtio_ring: unify

While porting LLDB over to StringRef, I am continuously running into difficulties caused by the fact that StringRef cannot be constructed from nullptr. So I wanted to see peoples' thoughts on removing this restriction from StringRef. To be clear, I'm only using LLDB as a motivating example, but I'm not requesting that it be done because LLDB is some kind of special case. If it is to

...plain; charset="us-ascii" > > Returning to an old discussion here.... > > On Aug 18, 2010, at 10:42 AM, Chris Lattner wrote: > > > On Aug 18, 2010, at 10:27 AM, Bob Wilson wrote: > >>> I tend to think that it isn't worth the compile time to try to > microoptimize out every compare, but I could be convinced otherwise if there > are important use cases we're failing to handle. I also do think that > whole-function selection dags will solve a lot of grossness (e.g. much of > codegen prepare) with a very clean model. > >> > >>...