search for: microoptimizing

Displaying 19 results from an estimated 19 matches for "microoptimizing".

2010 Aug 18
0
[LLVMdev] global type legalization?
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. >
2010 Aug 18
4
[LLVMdev] global type legalization?
On Aug 18, 2010, at 9:56 AM, Chris Lattner wrote: > On Aug 18, 2010, at 9:22 AM, Bob Wilson wrote: >> 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. > > That's true, but doing isel as a purely local approach
2004 Aug 24
0
[LLVMdev] More Encoding Ideas
...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/
2016 Sep 26
2
Is it time to allow StringRef to be constructed from nullptr?
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
2010 Aug 18
0
[LLVMdev] global type legalization?
On Aug 18, 2010, at 9:22 AM, Bob Wilson wrote: > 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. That's true, but doing isel as a purely local approach isn't the best either :-). We'd really like to get to
2010 Aug 18
3
[LLVMdev] global type legalization?
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
2007 Dec 27
0
[LLVMdev] llvm-gcc-4.2 and gfortran
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.
2014 Dec 12
2
[LLVMdev] [RFC] Stripping unusable intrinsics
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,
2007 Dec 27
2
[LLVMdev] llvm-gcc-4.2 and gfortran
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
2011 Jan 09
2
[LLVMdev] Increasing TargetRegisterInfo::FirstVirtualRegister?
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
2004 Aug 24
4
[LLVMdev] More Encoding Ideas
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
2010 Sep 14
1
[LLVMdev] global type legalization?
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
2013 Nov 12
0
[LLVMdev] How to reduce the footprint of MDNodes? (About the comment you made at BOF LTO)
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,
2013 Nov 12
3
[LLVMdev] How to reduce the footprint of MDNodes? (About the comment you made at BOF LTO)
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
2013 Nov 13
3
[LLVMdev] How to reduce the footprint of MDNodes? (About the comment you made at BOF LTO)
On Nov 12, 2013, at 1:28 PM, Chandler Carruth <chandlerc at google.com> wrote: > 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:
2014 Sep 03
8
[PATCH 0/3] virtio: simplify virtio_ring.
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
2014 Sep 03
8
[PATCH 0/3] virtio: simplify virtio_ring.
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
2016 Sep 25
8
Is it time to allow StringRef to be constructed from nullptr?
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
2010 Sep 15
0
[LLVMdev] LLVMdev Digest, Vol 75, Issue 32
2010/9/15 <llvmdev-request at cs.uiuc.edu> > Send LLVMdev mailing list submissions to > llvmdev at cs.uiuc.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > or, via email, send a message with subject or body 'help' to > llvmdev-request at cs.uiuc.edu > > You can