similar to: [LLVMdev] Testing a register allocator

> Hi! > > I developed a register allocator within LLVM and now I need to test its > efficiency. Can I do this using llvm-test package? > Do llvm tests check all available regalloc options automatically? If not, > then what modifications should I do to the test files? > It would be great if I could test my algo along with linearscan and compare > the results. > >

Hi again! I've managed to run the llvm-test with the options Fernando told. What I did was the following: I changed llc regalloc option in TEST.llc.makefile to my allocator. I changed LLCBETAOPTION in makefile.programs file for all architechtures to use my allocator. I run make TEST=nightly report.html and got all tests under LLCBETA failed ('*' symbol). Though I know that my

> > If the test output claims that llc-beta fails, then your register > allocator is producing incorrect code. Ok, I run make TEST=llc report.html with default allocator, not mine. Why LLCBETAOPTION for X86 is local, not linearscan? I've got some tests having * in some columns (for example, in column with register spills count). Does it mean that the test failed? Thanks.

On Sun, 3 Sep 2006, Tanya M. Lattner wrote: >> BTW, how can I run all tests only on LLC to reduce the amount of time to >> wait until tests are finished, if it's possible? > > In my previous reply to your question, I suggested you look at > TEST.llc.Makefile and TEST.llc.report in the test directory. Modifying > those makefile/report files to use your register allocator

Hi! I've did what Jim Laskey wrote but llc didn't reckognize my regalloc option. So I moved my allocator implementation into seperate folder within CodeGen and wrote separate makefile for it (like in "Writing an LLVM pass" tutorial). But when I run "make" from LLVMOBJDIR it doesn't enter the RegAlloc directory and when linking llc an error like

I managed to link my RegAlloc.a library to llc tool but can;t make the same with lli tool. Should I use USEDLIBS variable in lli makefile (like llc) or there is another way? On 8/20/06, Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > > Dear Anton, > > you can add your register allocator strait iin the > "lib/CodeGen/Passes.cpp", and then

Yes please. Evan On Oct 5, 2007, at 11:55 AM, Arnold Schwaighofer wrote: > > On 5 Oct 2007, at 20:47, Evan Cheng wrote: > >> >> On Oct 5, 2007, at 10:56 AM, Arnold Schwaighofer wrote: >> >>> >>>> We can set a policy of treating fastcc external functions >>>> as c functions. Then there is no chance of introducing ABI >>>>

On Oct 2, 2007, at 2:27 AM, Arnold Schwaighofer wrote: > Hi all, > > I changed the code that checks whether a tail call is really > eligible for optimization so that it performs the check/fix in > SelectionDAGISel.cpp:BuildSelectionDAG() as suggest by Evan. Also > eliminated an error that caused the remaining failing test cases in > the test-suite. > > The

Another round ;) Sadly not beer. tested against r42630 darwin-x86: SPASS llc-beta still fails thanks for the patience On 5 Oct 2007, at 20:58, Evan Cheng wrote: > Yes please. >> okay then i'll make tailcallopt switch stack adjusting behaviour? the patch for the test suite (when/if it's needed) would be something like: >>>>> --- Makefile.programs (revision

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

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

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 Tue, 25 Sep 2007, Evan Cheng wrote: >> the stack adjustment only fastcc was not one of them. Now that fastcc >> can cause tail call optimization i had to change the convention from >> caller pops arguments to callee pops arguments in order to allow tail >> call optimization in a general way. > > Hmmm. Ok. So this is due to X86CallingConv.td changes? Unfortunately

On 4 Oct 2007, at 00:22, Evan Cheng wrote: >> ifeq ($(ARCH),x86) >> LLCBETAOPTION := -regalloc=local -fast -tail-call-opt -tail-call-opt- >> align-stack > Please remove -regalloc=local -fast. We want to test this patch > separately. just did a test with LLCBETAOPTION := -tail-call-opt -tail-call-opt-align-stack this time only SPASS llc-beta fails (comparing with vanilla

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

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:

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

Hi all, I changed the code that checks whether a tail call is really eligible for optimization so that it performs the check/fix in SelectionDAGISel.cpp:BuildSelectionDAG() as suggest by Evan. Also eliminated an error that caused the remaining failing test cases in the test-suite. The results look very nice (on darwin x86, r42486). The same number (46) of failing test cases on patched

On Thu, 3 Aug 2006, Jim Laskey wrote: > To force the load/linking of your register allocator into the llc/lli tools, > add your create function's global declaration to "Passes.h" and add a > "pseudo" call line to "llvm/Codegen/LinkAllCodegenComponents.h" . Another note: with this new functionality you should be able to dynamically load register