search for: dalessandro

On Apr 14, 2009, at 1:49 PM, Luke Dalessandro wrote: > > On Apr 14, 2009, at 12:48 PM, Brice Lin wrote: > >> I just read the LLVM Programmer's Manual, which mentions (but >> specifically does not include any details of) the InstVisitor >> template. Could someone please provide an example of how to use this >&...

On May 17, 2009, at 5:23 AM, Luke Dalessandro wrote: > Owen Anderson wrote: >> >> On May 16, 2009, at 7:47 PM, Luke Dalessandro wrote: >> >>> Also, atomic ops are usually pretty low level things used for >>> nonblocking algorithms or to build higher level locking >>> constructs. Is >>&gt...

...ons, and BasicBlocks multiple times (once to find strcpy, another to find strcat, and so on for various other functions). If I only care about the direct calls, would I benefit more from switching to multiple use_iterators or the InstVisitor template? - Brice On Tue, Apr 14, 2009 at 1:13 PM, Luke Dalessandro <luked at cs.rochester.edu> wrote: > > On Apr 14, 2009, at 1:49 PM, Luke Dalessandro wrote: > > I guess I should note that the "use iteration" will only work for > direct calls. If you are concerned with indirect calls you need an > alias analysis or call graph or...

On May 16, 2009, at 7:47 PM, Luke Dalessandro wrote: > Owen Anderson wrote: >> Some of you may have noticed that I addedd include/llvm/System/ >> Atomics.h >> to the repository briefly, which will be used for adding support for >> threading in LLVM. > > Just out of curiosity, is there a design document somewh...

On Tue, Oct 29, 2019 at 08:19:20AM -0400, Dennis Dalessandro wrote: > On 10/28/2019 4:10 PM, Jason Gunthorpe wrote: > > From: Jason Gunthorpe <jgg at mellanox.com> > > > > This converts one of the two users of mmu_notifiers to use the new API. > > The conversion is fairly straightforward, however the existing use of > &gt...

Owen Anderson wrote: > > On May 16, 2009, at 7:47 PM, Luke Dalessandro wrote: > >> Also, atomic ops are usually pretty low level things used for >> nonblocking algorithms or to build higher level locking constructs. Is >> that the plan here too? It seems like you'd want to avoid anything too >> fancy since LLVM has to run on so many diff...

Luke Dalessandro wrote: > S. Bharadwaj Yadavalli wrote: >> $ ../../../src/llvm-gcc-4.2/configure >> --prefix=<llvm-root>/install/x86_64-arm/llvm-gcc-4.2 >> --program-prefix=llvm-x86_64-arm >> --enable-llvm=<llvm-root>/install/x86_64-arm/llvm >> --enable-languages=c,c...

From: Jason Gunthorpe <jgg at mellanox.com> This converts one of the two users of mmu_notifiers to use the new API. The conversion is fairly straightforward, however the existing use of notifiers here seems to be racey. Cc: Mike Marciniszyn <mike.marciniszyn at intel.com> Cc: Dennis Dalessandro <dennis.dalessandro at intel.com> Signed-off-by: Jason Gunthorpe <jgg at mellanox.com> --- drivers/infiniband/hw/hfi1/file_ops.c | 2 +- drivers/infiniband/hw/hfi1/hfi.h | 2 +- drivers/infiniband/hw/hfi1/user_exp_rcv.c | 146 +++++++++------------- drivers/infiniband/...

On Wednesday 25 March 2009, Luke Dalessandro wrote: > You could encode this information as simple library function calls and > then find them again in the generated LLVM IR. The client then just > needs a header declaring the functions and information on what they > mean. Since there are never any definitions of them they won'...

Mike Stump wrote: > On Oct 31, 2008, at 1:10 PM, Luke Dalessandro wrote: >> I've started trying by trying to get sparc-sun-solaris2.10 (niagara) >> working. It appears that neither llvm nor llvm-gcc will build natively >> on the system, so I think that I need to build an llvm-gcc cross >> compiler. > > Get a gcc binary from so...

I have a transformation where I'd like to use both DominatorTree (for ExtractCodeRegion), and DemoteRegisterToMemory (i.e., reg2mem). The transformation is phased, so all occurrences of getAnalysis<DominatorTree>(Function) happen before any occurrence of getAnalysisID<FunctionPass>(&DemoteRegisterToMemoryID, Function). If I register these two passes with DominatorTree first, I

Mike Stump wrote: > On Mar 24, 2009, at 8:40 AM, Luke Dalessandro wrote: >> Can someone more familiar with the llvm-gcc infrastructure comment on >> the difficulty of generating more strongly typed virtual function >> tables >> rather than just having them all be variable length arrays of pointers >> of unknown type and casting to...

Luke Dalessandro wrote: > OK. So I've discovered --with-sysroot which seems to be grabbing and > patching the include files correctly. Now it's dieing with > > ./options.h:462: error: 'HOST_BITS_PER_INT' undeclared here (not in a > function) > ./options.h:462: error: bit-f...

On 30 August 2010 12:43, Luke Dalessandro <luked at cs.rochester.edu> wrote: > I have gold from cvs, and llvm-gcc/llvm from svn. My platform is > Ubuntu 9.04 x86_64. I've configured llvm-gcc with "--enable-multilib". > > When compiling the LTO example from > http://llvm.org/docs/LinkTimeOptimization.html...

On Oct 20, 2010, at 4:05 AM, Luke Dalessandro wrote: > If I register DemoteRegisterToMemoryID first I'd expect this to work. > then I get this assert during code extraction. > > CodeExtractor.cpp:681: llvm::Function*<unnamed>::CodeExtractor::ExtractCodeRegion(const std::vector<llvm::BasicBlock*, std::allocator<...

...mellanox.com> > > This converts one of the two users of mmu_notifiers to use the new API. > The conversion is fairly straightforward, however the existing use of > notifiers here seems to be racey. > > Cc: Mike Marciniszyn <mike.marciniszyn at intel.com> > Cc: Dennis Dalessandro <dennis.dalessandro at intel.com> > Signed-off-by: Jason Gunthorpe <jgg at mellanox.com> I tested v1, and replied to it [1]. I can re-test with this version if you like as well. [1] https://marc.info/?l=linux-rdma&m=157235130606412&w=2 -Denny

I'm curious about the type erasure that goes on when llvm-g++ compiles C++ code. Is this a consequence of it just being the easiest way to do things based on the design of gcc and how LLVM is plugged into it? Can someone more familiar with the llvm-gcc infrastructure comment on the difficulty of generating more strongly typed virtual function tables rather than just having them all be

On Apr 1, 2009, at 7:25 AM, Torvald Riegel wrote: > On Wednesday 25 March 2009, Luke Dalessandro wrote: >> You could encode this information as simple library function calls >> and >> then find them again in the generated LLVM IR. The client then just >> needs a header declaring the functions and information on what they >> mean. Since there are never any defini...

On Oct 31, 2008, at 1:10 PM, Luke Dalessandro wrote: > I've started trying by trying to get sparc-sun-solaris2.10 (niagara) > working. It appears that neither llvm nor llvm-gcc will build natively > on the system, so I think that I need to build an llvm-gcc cross > compiler. Get a gcc binary from someplace, use that to then...

On Mar 24, 2009, at 10:22 AM, Luke Dalessandro wrote: > OK, so it's mainly a problem of becoming comfortable with the llvm-gcc > internals that are affected and not a fundamental whole-compiler > design > problem. That's correct. > So I can essentially rematerialize the vtable types by pushing things > back through...