search for: synputer

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

Alkis Evlogimenos wrote: >As for CVS, I am not sure this should be fixed because there is >really no LLVM bug here :-) > > > No, you are right. But perhaps it is worth it to mention the problem somewhere in the documentation, because there appear to be many installations with this problem (I've found 3: my home installation, my work and the nearest university), and it is

Chris Lattner wrote: >While this is not an LLVM bug, if Finn has run into it, other people >probably will too. I've fixed it in CVS: if you update llvm/lib/CodeGen >and rebuild, hopefully linscan will magically work for Finn now. :) > >-Chris > > It works. Even better: it isn't magic ;-) Thank you for helping me out. Now it's time to play :) Best regards /Finn

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),

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

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

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

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

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

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

Hi, I have a question about x86 code quality. I have run a few benchmarks and compared the running time of executables created by LLVM to executables created by gcc. It appears that code generated by LLVM is x1.5 - x3 times slower than code generated by gcc, for the x86 For some of the benchmarks the linear scan regalloc works. When it does, results are in the x1.0 - 1.5 range. Unfortunately,