similar to: [LLVMdev] RegAllocSimple.cpp

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

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

Hi, attached is a patch which solves the following problem: Sometimes scp could hang in Cygwin when used as remote end using the -t option. This is due to a binmode/textmode problem which could be raised by the login shell which is used by the user and it's setting of textmode on stdin. The patch solves that problem by explicitly setting binmode on stdin. Besides solving the hanging

What is the status of RegAllocLocal, RegAllocBigBlock and RegAllocSimple allocators? I am considering using one of them as a basis for a course project on register allocation in my class. In particular, are those allocators in regular use and/or have they been tested recently? I am particularly interested in the code as of version 4.0 but if anything has improved since then, the

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

Oops! Nevermind. I see that it's being deallocated in another class. My bad. -bw

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

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

Morten, The leaks.patch file introduced a static destructor ordering problem which lead to garbled output. The comment above those lines of code indicates why it needs to be the way it is. My bad for committing it in the first place. Please be careful in the future. Reid. On Mon, 2004-12-13 at 05:30, Morten Ofstad wrote: > Hi, > > here are some minor patches that for various reasons

Any ideas? Instruction uses an alias of an allocated register UNREACHABLE executed at RegAllocFast.cpp:358! 0 clang 0x0000000101309bc2 PrintStackTrace(void*) + 34 1 clang 0x000000010130a863 SignalHandler(int) + 707 2 libSystem.B.dylib 0x00007fff8056935a _sigtramp + 26 3 libSystem.B.dylib 000000000000000000 _sigtramp + 2141809856 4 clang 0x00000001012dd96d

The attached patch fixes bugs related to MachineBasicBlock::iterator. I don't have any test cases that reproduce on an X86 machine the problems that this patch fixes (these bugs were found when make check was run on a mips board). Please review. The first part just ensures that iterator I is not instr_end() before it invokes isInsideBundle(). The second part changes the signature of spillAll

Hi, here are some minor patches that for various reasons I've not submitted yet - I'm just trying to clear my list of differences before christmas... First of all the clear.patch file contains a patch that enables the JIT to drop all global mappings. I need this because when I have N threads I compile N different versions of my functions using different memory areas for global

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

On Sep 19, 2008, at 2:41 AM, Matt Elder wrote: > 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

I just changed the default register allocator for -O0 builds to the fast allocator. This means that the local register allocator is not used anymore, and since it does more or less the same as the fast allocator, there is no reason to keep it around. I am going to delete it in a week or two. If you are using the local register allocator, please try switching to the fast allocator and report any

On Thu, 2010-06-03 at 02:53 +0200, Jakob Stoklund Olesen wrote: > If you are using the local register allocator, please try switching to the fast allocator and report any bugs you find. > Tried it, and it seems to break quite a big chunk of our tests on SPU :) Before r103488 ("Mostly rewrite RegAllocFast") there was no problem. But with r103488, I get a:

Hi Susan, > But this doesn't seem to be happening; the stores to memory are there but > the loads are not. > > Any ideas what's going wrong? Are you using VirtRegMap::addSpillPoint and VirtRegMap::addRestorePoint ? If not you may need to add calls to them to let the rewriter know where to insert the loads/stores. > If not, any advice on how to generate the loads

I found the problem! My generated code is spilling correctly but is not reloading at all. For example, if the original code has the equivalent of this (where %1024 is a virtual reg): %1024 = xxx ... yyy = %1024 and I find no physical register for %1024, then I assign it to physical register %edi and to a stackslot. That creates code like this: %edi = xxx store from %edi to the

I was playing with optimization switches to llc to see how fast I could get it to compile but it keeps barfing. Tinkering indicates that llc barfs particularly when -tailcallopt is given in combination with other flags. For example, without -tailcallopt works in a couple of ways: $ llc -O0 -f aout.bc -o aout.s $ llc -O0 --regalloc=local -f aout.bc -o aout.s But fails with -tailcallopt with