similar to: [LLVMdev] Question about register allocators

On Wednesday 11 July 2007 15:07, Christopher Lamb wrote: > Could it be possible for there to be a harness type interface that > would allow coalescers that support both modes to be hooked into the > pass registration, and those that depend on the allocator not be > registered as passes? I have a patch for this kind of thing attached. Please take a look and let me know if it looks

On Jul 11, 2007, at 11:39 AM, David Greene wrote: > On Wednesday 11 July 2007 12:41, Tanya M. Lattner wrote: > >> I think the coalescer should be flexible enough to be run >> independent of >> the register allocator. For example, you may want to expose the >> copies >> induced by transforming out of SSA to the scheduler. If the >> scheduler is

Hi, right now, LLVM does register spilling by: 1. Creating stack object 2. Passing index of that stack object to MRegisterInfo::storeRegToStackSlot 3. At later stage, frame indices are replaced by calling to MRegisterInfo::eliminateFrameIndex. This works for me, but there's slight problem. The target does not have "register + contant" addressing mode, so accessing frame index

On Tue, 23 May 2006, Vladimir Prus wrote: > right now, LLVM does register spilling by: > > 1. Creating stack object > 2. Passing index of that stack object to MRegisterInfo::storeRegToStackSlot > 3. At later stage, frame indices are replaced by calling to > MRegisterInfo::eliminateFrameIndex. > > This works for me, but there's slight problem. The target does not have

Hi Chris, I saw this potential memory leak in RegAllocSimple.cpp. The PhysRegsEverUsed was being allocated but never freed. -bw Index: RegAllocSimple.cpp =================================================================== RCS file: /var/cvs/llvm/llvm/lib/CodeGen/RegAllocSimple.cpp,v retrieving revision 1.66 diff -a -u -r1.66 RegAllocSimple.cpp --- RegAllocSimple.cpp 22 Jan 2006 23:39:54 -0000

Chris Lattner wrote: >> and then have 'virtual_register' allocated on next iteration of register >> allocator? > > This is one approach. Another approach is to have to spiller scavange > registers, which is the subject of this enhancement request: > http://llvm.org/PR768 Can you given some references for this "scavange" thing? Google and ResearchIndex

I tried both the most recent version of "simple" register allocation and the one from last August, and neither seems to work correctly (they run, but produce bad output). I used them to compile an old version of the Unix "replace" utility (source code attached). Here's how I created the executable: llvm-gcc -emit-llvm -O0 -c replace.c -o replace.bc opt -mem2reg

lib/CodeGen/RegAllocLocal.cpp:38: warning: 'NumFolded' defined but not used This has been introduced because of r46821. However, maybe removing just the variable isn't enought, because the comments in the section that got modified by 46821 are not optimal: if (PhysReg) { // Register is available, allocate it! assignVirtToPhysReg(VirtReg, PhysReg); } else { // No

Hi everyone, Quick summary: LLVM now has a new register allocator particularly suitable for compiling (very) large, machine-generated functions. Longer story: I've recently been using LLVM in an application that involves JITing fairly large functions that have no control flow - they're just flat sequences of instructions, anywhere from 100 to 10000+ in size. (The control flow is

I'm trying to piece together a few assignments for a graduate-level compilers class using LLVM; among these is a register allocator. I'd like to provide a register allocator that, given a partially-allocated VirtRegMap, will perform trivial register allocation (as in RegAllocSimple) on the remaining, unmapped virtual registers. To make a long story short, I want to map a single

I'm encountering a new problem building llvm (from CVS) on Solaris. The tblgen executable builds successfully but it seems to use the wrong version of libstdc++ : % /home/vadve/vadve/llvm-sparc/Debug/bin/tblgen --help ld.so.1: /home/vadve/vadve/llvm-sparc/Debug/bin/tblgen: fatal: /home/ vadve/lattner/local/x86-fc1/gcc-3.4.2/lib/libstdc++.so.6: wrong ELF class: ELFCLASS32 Killed This

On Feb 23, 2009, at 10:30 AMPST, Aaron Gray wrote: > On Mon, Feb 23, 2009 at 6:22 PM, Aaron Gray <aaronngray.lists at googlemail.com > > wrote: > On Mon, Feb 23, 2009 at 6:09 PM, Dale Johannesen <dalej at apple.com> > wrote: > These benchmarks are not distributed with llvm (which doesn't have the > legal right to distribute Spec, for example). If you have

Dear Prof. Adve, Now I can use llvmgcc to compile a .c file into .bc file. But I still have trouble simply run the .bc code. Below is the sequence I got when I tried. I really don't know what's going on here. Please let me know how can I fix it. Thanks, xiaodong xli3|csil-suna48|~/cs426|[13]% llvmgcc scalarize.c -o scalarize xli3|csil-suna48|~/cs426|[14]% scalarize Cannot load value of

That sounds like a problem. Just so I understand, do you mean there isn't the run-time support etc. to write back ends for the C++ language, or that the compiler IR is also somehow insufficient to write a code generator? --Vikram Associate Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve On Jul 11, 2009, at 3:00 PM, Granville Barnett

When you create a parser via ANTLR you specify the output language of the resulting recursive descent parser, at the moment there exists no C++ output template to my knowledge, thus you would have to generate the parser as C code for which a template exists. The runtime support should be there, at least partially but it won't use things like exceptions, nor will it have a very modular design

On Apr 26, 2006, at 10:45 AM, Tom Tromey wrote: >>>>>> "Vikram" == Vikram Adve <vadve at cs.uiuc.edu> writes: > > Vikram> Either way, one issue that you will have to deal with is > preserving > Vikram> the behavior of Java exceptions (assuming you care about > that). LLVM > Vikram> does not preserve the order of potentially

Dear All, Here's a question Vikram and I received. Is the LLVM JIT thread safe? -- John T. -------------- next part -------------- An embedded message was scrubbed... From: "Adve, Vikram Sadanand" <vadve at uiuc.edu> Subject: Fwd: LLVM and threading Date: Thu, 1 Nov 2007 09:48:59 -0500 Size: 3037 URL:

Dale Johannesen wrote: > On Feb 23, 2009, at 10:30 AMPST, Aaron Gray wrote: > > On Mon, Feb 23, 2009 at 6:22 PM, Aaron Gray <aaronngray.lists at googlemail.com<mailto:aaronngray.lists at googlemail.com>> wrote: > On Mon, Feb 23, 2009 at 6:09 PM, Dale Johannesen <dalej at apple.com<mailto:dalej at apple.com>> wrote: > These benchmarks are not distributed with

On Oct 15, 2009, at 10:45 AM, Chris Lattner wrote: > Unfortunately, we found out at the last minute that Apple has a rule > which prevents its engineers from giving video taped talks or > distributing slides. We will hold onto the video and slide assets in > case this rule changes in the future. > > -Chris Chris, I hope you can pass my message along to the people at Apple

Our department outreach coordinator spotted this and forwarded it to me. It's a lot of speculation but I thought many of you would be interested. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.org Begin forwarded message: > From: "Jennifer C La Montagne" <jsandone at uiuc.edu> > Date: June 8, 2007 12:53:00 PM CDT > To: "Vikram Sadanand Adve"