search for: romix

Hi again, 2009/1/13 Evan Cheng <evan.cheng at apple.com>: > > > On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com> > wrote: > >> 2009/1/13 Evan Cheng <echeng at apple.com>: >>> >>> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: >>> >>>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: >>>> Predecessors according to...

On Jan 23, 1:51 pm, Roman Levenstein <romix.l... at googlemail.com> wrote: > Hi, > > Doing some profiling of llc, I noticed that some bitvector operations > took longer than usual. Then I noticed that too many copies of > BitVector obejcts are created, even when such operations like &=, ^=, > |= are performed on thos...

Hi, Doing some profiling of llc, I noticed that some bitvector operations took longer than usual. Then I noticed that too many copies of BitVector obejcts are created, even when such operations like &=, ^=, |= are performed on those bit vectors. I looked at the BitVector ADT implementation in BitVector.h and figured out that all assignment operations (except the usual assignment operator)

On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com > wrote: > 2009/1/13 Evan Cheng <echeng at apple.com>: >> >> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: >> >>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: >>> Predecessors according to CFG: 0x8fdac90 (#0) >>&g...

2009/1/13 Evan Cheng <echeng at apple.com>: > > On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: > >> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: >> Predecessors according to CFG: 0x8fdac90 (#0) >> %R0<def> = MOVi 0, 14, %reg0, %reg0 >> *** STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4) >> [0x8fc2d68 + 0]

Hi, Here is yet another bug/miscompilation I've found while testing my register allocator. The compilation of the attached BC file fails on multiple backends, namely: ia64, mips, mipsel, alpha The failures are different from backend to backend (wrong register classes, wrong operand types, etc). Please, just try to compile using the attached BC file. I guess, it is related to the FP

...to hear what others think about - custom allocators, - reasons for current inefficiency of many STL containers on Evan's/Chris configs and - possibility of using 3rd party libs like Boost (or their parts) in LLVM Thanks, - Roman ----- Forwarded Mail ---- > From: Roman Levenstein <romix.llvm at googlemail.com> > To: CVS Commit Messages for LLVM repository <llvm-commits at cs.uiuc.edu> > Send: Friday, 16. May 2008, 19:20:29 > Subject: Re: [llvm-commits] Speeding up RegAllocLinearScan on big test-cases > > Hi, > > 2008/5/7 Evan Cheng : > > Can...

Hi, It looks like LiveIntervals::addIntervalsForSpills does not update all of the LiveIntervals infos quite correctly. In particular, if a live interval L is defined by Reg<-Reg copy instructions whose srcReg is later spilled by the addIntervalsForSpills() function, its VNInfo information is not updated in a proper way. It still points to the same MachineInstr as before, even though the

Hi, Compilation of the the following very simple file crashes with --march=ia64 on my x86 machine. ; ModuleID = 'bugpoint-reduced-simplified.bc' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" target triple = "i386-pc-linux-gnu" @x = weak global [8 x i32] zeroinitializer, align

Hi Richard, Thanks for working on this! Your patched solved my initial problem, but introduced another one. Please find attached another BC file that fails on xcore with the linear scan regalloc. This is the error message I get eliminateFrameIndex Frame size too big: -3 0 llc 0x08affd1e 1 libc.so.6 0xb7d35a01 abort + 257 2 llc 0x081a0972

Hi Lang, There are at least two projects that were using BigBlock, directly or indirectly. One approach is described in the paper "Register Spilling and Live-Range Splitting for SSA-Form Programs" by Matthias Braun and Sebastian Hack. It can be found here: http://pp.info.uni-karlsruhe.de/publication.php?id=braun09cc http://pp.info.uni-karlsruhe.de/uploads/publikationen/braun09cc.pdf

Hi Chris, 2009/7/30 Chris Lattner <clattner at apple.com>: > > On Jul 29, 2009, at 3:14 PM, Roman Levenstein wrote: > >> Hi Lang, >> >> There are at least two projects that were using BigBlock, directly or >> indirectly. > > Hi Roman, > > We have many plans to rip out linscan and replace it with something > that handles large blocks better.

Hi again, Now, after I fixed the graph coloring regalloc bug that was triggered by the ARM target, I continue testing and found another bug, this time on the XCore target. First I thought that it is again specific to my register allocator, but it seems to be trigerred also by LLVM's linearscan register allocator. I don't know if the XCore target is stable enough in LLVM, or may be I

Hi Evan, Thanks a lot for your reply! 2009/2/27 Evan Cheng <evan.cheng at apple.com>: > > On Feb 27, 2009, at 7:20 AM, Roman Levenstein wrote: > >> Hi, >> >> I'm working on the implementation of Extended Linear Scan register >> allocator as described by Sarkar & Bodik. >> One of the interesting features of their algorithm is the possibility

Hi, I'm working on the implementation of Extended Linear Scan register allocator as described by Sarkar & Bodik. One of the interesting features of their algorithm is the possibility to allocate different physical registers to different live-ranges of the same LiveInterval. Of course, it may require some glue code to be inserted in cases, where different physical regs were assigned to

Hi, While testing my new register allocators on some test-cases, I've noticed that LLVM misses sometimes some optimization opportunities: 1) LocalSpiller::RewriteMBB seems not to propagate the information about e.g. Spills between MBBs.In many cases, where MBB B1 has only one predecessor MBB B2, B1 could reuse the information about the physical registers that are in the live-out set of B2.

Hi Evan, Thanks for your feedback! 2009/1/7 Evan Cheng <evan.cheng at apple.com>: > > On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: > > > As you can see, PrologEpilogInserter has inserted at the beginning > of the function some code for manipulation of the frame pointer and > this inserted code uses the LR register. > As far as I understand,

Hi, I'm working on the iterated register coalescing graph coloring allocator and try to test it with all backends available currently in LLVM. Initial tests with most of the backends are successful. It turned out that my allocator triggers a specific assertion in the RegScavenger and only for the ARM target. It looks like the LR register is used for frame pointer related things, but it is

Hi, I'm implementing some variations of graph-coloring register allocators for LLVM. Many of them perform their phases (e.g. coalescing, graph simplification, spilling, color selection) in an iterative way. Since LLVM provides an implementation of the coalescing in the SimpleRegisterCoalescing class already, I would like to reuse it (even though I could of course create my own coalescing