similar to: [LLVMdev] olden bmks

On Sun, 8 Dec 2002, Chris Lattner wrote: > > For each bmk, the undefined symbols are coming from args.c as far as I can > > tell. Do I need to link in args.c's bc file for each of them or am I > > doing something terribly wrong? > > These benchmarks were compile a long time ago in a galaxy far far away. > In this galaxy, uninitialized globals (int X;) were handled

> For each bmk, the undefined symbols are coming from args.c as far as I can > tell. Do I need to link in args.c's bc file for each of them or am I > doing something terribly wrong? These benchmarks were compile a long time ago in a galaxy far far away. In this galaxy, uninitialized globals (int X;) were handled differently, so how these old bytecode files aren't useful anymore.

On Sun, 8 Dec 2002, Chris Lattner wrote: > If you recompile the bytecode files now, (go into each directory and type > 'make final' they should be ok. Perhaps someone can do this and post the > results for everyone to use... I put up what I could compile here: http://tank.cs.uiuc.edu/Olden/ However, I could not get mst to compile: % make final dis: bytecode didn't read

On Sun, 8 Dec 2002, Chris Lattner wrote: > Olden itself doesn't need it. _Compiling_ Olden requires the assembler to > turn llvm .s files into llvm .o files. Why not just use the bytecode > files that Misha posted? Right now I can't even get the LLVM assembly file to produce from Olden. The bytecodes that Misha posted are some ancient Olden version that doesn't work

What exactly does Olden require from 'as'. I can't build the entire 'as' because there's no more disk space left. Wojciech

does anyone knows how to get the Olden BM bytecode files? We're low on disk space and I don't want to build the whole test branch (even if i can, which I doubt, it failed last time i tried).

I've also been trying to compile the Olden benchmarks in /test/Programs/MultiSource/Olden-* but to no effect. I just did a full CVS update -d on the llvm tree but when I try compiling say Olden-bh I get this error: gmake: *** No rule to make target `Output/args.rbc', needed by `Output/bh.linked.rbc'. Stop. We've also tried downloading the Olden benchmarks directly from the URL

When I run with -steens-aa, I get lots of error messages like the following: MergeTypeInfo Folding OrigTy: uint due to:sbyte @ 0! SubType: uint and then it dies with: Assertion failed: Index < Links.size() && "Link index is out of range!", file ../../../include/llvm/Analysis/DSNode.h, line 120 Am I doing something wrong, or is this analysis under development still?

I must be doing something dumb, but I'm having trouble running the example hello transformation. It is printing "pure virtual method called." All I am doing is checking out a new llvm, compiling it with gmake -k, compiling Hello with gmake, and running: opt -load ../../../lib/Debug/libhello.so -hello < hello.bc > /dev/null where hello.bc is the hello world program. From

I have a sort of strange request -- I am splitting up a program into multiple threads, which may have duplicated instructions between them. I'd like to run optimizations on the threads separately, but I'd like for the variables common amongst the threads to get register allocated the same way (i.e, a value that is duplicated in the two threads gets mapped to the same register/memory

I noticed that the open projects lists porting glibc to LLVM. I was wondering if anyone was working on this currently. If no one is on it, does anyone have an idea of how nasty this would be to do? I'd like to have LLVM output to a new ISA, it'd be great if all I had to do was proxy system calls like read and write in my architectural simulator. -- Francesco Spadini

> Note that compiling glibc with LLVM does not give you a solution to THIS > problem: you'd still have to write a new backend for your ISA. There is > currently a Sparc backend and an X86 backend. Depending on how similar > your architecture is to one or the other, you might be able to leverage > existing code. Take a look at llvm/lib/Target/{Sparc,X86}, though the > X86

Dear all, Sweave chokes when using "\\" in the path to the Rnw file. Using "/" works fine. The problem is that Eclipse+StatET uses "\\" in the filename. And example of the error, traceback and sessionInfo are given below. Best regards, Thierry > Sweave("Q:\\BMK\\cursussen\\interne_opleiding\\deelnemerslijst.Rnw", syntax="SweaveSyntaxNoweb")

> What exactly does Olden require from 'as'. I can't build the entire 'as' > because there's no more disk space left. Olden itself doesn't need it. _Compiling_ Olden requires the assembler to turn llvm .s files into llvm .o files. Why not just use the bytecode files that Misha posted? -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/

The new Olden benchmark bytecodes Misha generated are in the standard place: > Perhaps Chris could copy them into the standard place? Done: http://llvm.cs.uiuc.edu/LLVMPrograms/Olden -Chris > > The files I linked to the second time > > (http://tank.cs.uiuc.edu/Olden) are hot off > the presses: I > > compiled them just recently today. So far, only 2 of them give me

The following should work: % cd llvm/test/Programs/MultiSource % gmake DISABLE_CBE=1 DISABLE_LLC=1 --Vikram http://www.cs.uiuc.edu/~vadve > -----Original Message----- > From: llvmdev-admin at cs.uiuc.edu > [mailto:llvmdev-admin at cs.uiuc.edu] On Behalf Of Juan Nicolas Ruiz > Sent: Sunday, December 08, 2002 2:20 PM > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] Olden BM

On Sun, 8 Dec 2002, Juan Nicolas Ruiz wrote: > does anyone knows how to get the Olden BM bytecode files? http://llvm.cs.uiuc.edu/LLVMPrograms/Olden/ -- Misha Brukman :: uiuc.edu/~brukman

amd from the amd-920824upl102-6.i386.rpm file distributed with RedHat Linux 4.1 does not honor the nodev option for NFS filesystems and probably other mount types, allowing any user access to the device files in /dev on a system, provided that they have root access to another linux box on the network. In addition, the default amd.conf from RH 4.1 maps /net/* to NFS mounting, which makes the bug in

Hi, Below you can see the updated benchmark results for the new SLP-vectorizer. As you can see, there is a small number of compile time regressions, a single major runtime *regression, and many performance gains. There is a tiny increase in code size: 30k for the whole test-suite. Based on the numbers below I would like to enable the SLP-vectorizer by default for -O3. Please let me know if you

Hi, LLVM’s SLP-vectorizer is a new pass that combines similar independent instructions in a straight-line code. It is currently not enabled by default, and people who want to experiment with it can use the clang command line flag “-fslp-vectorize”. I ran LLVM’s test suite with and without the SLP vectorizer on a Sandybridge mac (using SSE4, w/o AVX). Based on my performance measurements