similar to: [LLVMdev] x86 cogen quality

On Wed, Apr 21, 2004 at 11:01:48AM +0200, Finn S Andersen wrote: > For some of the benchmarks the linear scan regalloc > works. When it does, results are in the x1.0 - 1.5 > range. Unfortunately, the linear scan allocator breaks > on most of my code. Is there a chance you can try cvs? I would be interested to get a simplified test case where the allocator breaks. A lot of

Alkis Evlogimenos wrote: >Is there a chance you can try cvs? I would be interested to >get a simplified test case where the allocator breaks. A lot of >improvements went into the x86 backend since 1.2 and we currently have >no test cases where the allocator breaks today. > > I updated and recompiled and the error is still there. It turns out that I cannot use the bugpoint

Alkis Evlogimenos wrote: >On Wed, Apr 21, 2004 at 11:01:48AM +0200, Finn S Andersen wrote: > > >>For some of the benchmarks the linear scan regalloc >>works. When it does, results are in the x1.0 - 1.5 >>range. Unfortunately, the linear scan allocator breaks >>on most of my code. >> >> > >Is there a chance you can try cvs? I would be

OK, details: I run RH8 (gcc 3.2.something), RH9 (gcc 3.2.2-5) and Fedora. Problems are the same across all setups. Hardware is Athlon 1600+ and half a giga RAM. Runs fail with an assertion when the linear scan allocator is enabled, but runs without problems otherwise. On RH9 (the system I have access to while generating this email) I have the following details: > 1) The LLVM assembly

Chris Lattner wrote: >I can't reproduce this failure with mainline CVS using either lli or llc: > >$ lli -regalloc=linearscan a.out.bc >$ echo $status >0 > >Are you sure that the CVS version is in your path? > > After configure and make I run make install, which moves the executables to /usr/local/bin, right ? And yes, they are in my path. But thank you very

Sorry to disturb you all, but I simply cannot get the linearscan allocator to work. I have upgraded llvm to mainline cvs. Everything works until I get to llc -regalloc=linearscan or lli -regalloc=linearscan. I have installed it on redhat 9 and on Fedora Core distributions (I even took it as far as to format a new partition and install Fedora core all over). I have submitted the bytecode that

Finn S Andersen wrote: > Chris Lattner wrote: > >> I can't reproduce this failure with mainline CVS using either lli or llc: >> >> $ lli -regalloc=linearscan a.out.bc >> $ echo $status >> 0 >> >> Are you sure that the CVS version is in your path? >> >> > After configure and make I run make install, which moves the executables

On Mon, 26 Apr 2004, Finn S Andersen wrote: > Alkis Evlogimenos wrote: > > >Is there a chance you can try cvs? I would be interested to > >get a simplified test case where the allocator breaks. A lot of > >improvements went into the x86 backend since 1.2 and we currently have > >no test cases where the allocator breaks today. > I updated and recompiled and the

Finn S Andersen wrote: > Sorry to disturb you all, but I simply cannot get > the linearscan allocator to work. I have upgraded > llvm to mainline cvs. Everything works until I get > to llc -regalloc=linearscan or lli -regalloc=linearscan. > > I have installed it on redhat 9 and on Fedora Core > distributions (I even took it as far as to format a new > partition and

Chris Lattner wrote: >You can check out the whole CVS tree at once, which is going to be a lot >easier than pulling it down from CVSweb :) Here are the instructions: >http://llvm.cs.uiuc.edu/docs/GettingStarted.html#checkout > Ouch, how embarrasing - I looked for that place, but apparently failed to notice it. Sorry. Anyhow, I checked it out as described (in a clean directory),

On Thu, 22 Apr 2004, Finn S Andersen wrote: > >Is there a chance you can try cvs? I would be interested to > >get a simplified test case where the allocator breaks. A lot of > >improvements went into the x86 backend since 1.2 and we currently have > >no test cases where the allocator breaks today. > > > > > I would, if I could. > But trying cvsweb I cannot

On Tue, 4 May 2004, Finn S Andersen wrote: > Chris wrote in a followup: > > > Can you send the output of 'llc -o - foo.bc -debug -print-machineinstrs'? > > > Attached as "linscan". (But added the "-regalloc=linearscan" to provoke > the error). Yes, that's exactly what I meant... thanks for reading my mind! :) It looks like this is where

Chris Lattner wrote: >I think that we should switch to C constants in this case. Can you try >#include <math.h> and use HUGE_VAL instead? > It works: [finna at coplin11 ~/test]$ cat tst.cpp #include <limits> #include <iostream> #include <math.h> int main() { std::cerr << std::numeric_limits<float>::infinity() << "\n"; std::cerr

On Thu, May 06, 2004 at 04:06:27PM +0200, Finn S Andersen wrote: > Chris Lattner wrote: > > >I think that we should switch to C constants in this case. Can you try > >#include <math.h> and use HUGE_VAL instead? > > > It works: > > [finna at coplin11 ~/test]$ cat tst.cpp > #include <limits> > #include <iostream> > #include

Chris Lattner wrote: >Could you try compiling and running this program: > >--- >#include <limits> >#include <iostream> >int main() { > std::cerr << std::numeric_limits<float>::infinity() << "\n"; >} >--- > > Sure thing. It prints "0". Calling that inifinity is somewhat of a stretch, isn't it ? What on earth

On Wed, 5 May 2004, Finn S Andersen wrote: > Chris Lattner wrote: > > >Could you try compiling and running this program: > > > >--- > >#include <limits> > >#include <iostream> > >int main() { > > std::cerr << std::numeric_limits<float>::infinity() << "\n"; > >} > >--- > > > > > Sure

On 20/09/05, Chris Lattner <sabre at nondot.org> wrote: > > because LiveVariables do not provide an interface to iterate through > > all viritual registers. > > Ok, you could add a method to LiveVariables that returns > VirtRegInfo.size(). The virtual registers are defined by the range: > [MRegisterInfo::FirstVirtualRegister, >

Dear Anton, you can add your register allocator strait iin the "lib/CodeGen/Passes.cpp", and then 're-make' it: "makellvm llc", on the top of lib/CodeGen. It is faster than running make from LLVMOBJDIR. The problem is that it only add to llc the changes on the lib/CodeGen directory. If you change other parts, a make from LLVMOBJDIR will synchronize it. Try adding

Hi all, I was looking at the register allocator code and had a question about that: CodeGen/RegAlloc/PhysRegAlloc.cpp implements a graph coloring register allocator for the Sparc back end. It requests target machine register information via a call to getRegInfo() which returns a class TargetRegInfo containing the required information. For the x86 target machine, this interface has not been

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: