search for: runund

I want to get lnt to use qemu for the execution. In that case, RHOST= is not set. But I change the Arch because I am going to run in cross mode. Then I'm setting RUNUNDER to be a script which runs qemu. In this case it builds timeit-target as a Mips which fails because this is running on x86. ~/mysandbox/bin/lnt runtest nt --sandbox ~/mysandbox --cc /local/llvmpb_a/install/bin/clang --cflag "-target mipsel-linux-gnu -EL -mips16 -gcc-toolchain /mips/ar...

...t flags if we are simulating the target on the host. On 06/06/2013 06:59 PM, reed kotler wrote: > I want to get lnt to use qemu for the execution. > > In that case, RHOST= is not set. > > But I change the Arch because I am going to run in cross mode. > > Then I'm setting RUNUNDER to be a script which runs qemu. > > In this case it builds timeit-target as a Mips which fails because this > is running on x86. > > ~/mysandbox/bin/lnt runtest nt --sandbox ~/mysandbox --cc > /local/llvmpb_a/install/bin/clang --cflag "-target mipsel-linux-gnu -EL > -m...

...pported by QEMU. > > But in this case, we would need to check in a version of QEMU and also > the needed pieces of a MIPS tool chain for assembly, linking, etc. > > Any thoughts on this? Why do you need changes to the scripts to make this work? The makefiles already support the $RUNUNDER option that we use to run tests under valgrind, which should be useable for qemu as well, perhaps with a shell script wrapper to get the arguments in the right format. --Owen

We have a modified version of projects/test-suite that we can run cross using Qemu. We would like to put that back so that other people can test MIPS before putting back. Well, this would be easily modifiable for ARM and other targets that are supported by QEMU. But in this case, we would need to check in a version of QEMU and also the needed pieces of a MIPS tool chain for assembly,

...--build-threads 6). This seems critical, I always do that. > * Make lnt use linux perf to get more accurate timing for short-running benchmarks (--use-perf=1) > * Pin the running benchmark to a specific core, so the OS doesn't move the benchmark process from core to core. (--make-param=RUNUNDER=taskset -c 1) > * Only run the programs that are marked as a benchmark; some of the tests in the test-suite are not intended to be used as a benchmark (--benchmarking-only) > * Make sure each program gets run multiple times, so that LNT has a higher chance of recognizing which programs are...

...ost one at a time. (--threads 1 --build-threads 6). > * Make lnt use linux perf to get more accurate timing for short-running > benchmarks (--use-perf=1) > * Pin the running benchmark to a specific core, so the OS doesn't move the > benchmark process from core to core. (--make-param=RUNUNDER=taskset -c 1) > * Only run the programs that are marked as a benchmark; some of the tests > in the test-suite are not intended to be used as a benchmark > (--benchmarking-only) > * Make sure each program gets run multiple times, so that LNT has a higher > chance of recognizing whic...

Hi, I'm trying to run the benchmark suite: http://llvm.org/docs/TestingGuide.html#test-suite-quickstart I'm doing it the lnt way, as described at: http://llvm.org/docs/lnt/quickstart.html I don't know what to expect but the results seems to be quite noisy and unstable. E.g I've done two runs on two different commits that only differ by a space in CODE_OWNERS.txt on my 12

Hi all, I'm working in a company to port LLVM on their own processor. I'm trying to run the test-suite, but it seems that it is usually run directly on the processor which is tested. In my case, I cannot run it on the processor, but I have a simulator on which I would like to run the test-suite. Also, it seems to me that the test-suite start by compiling some tools that have to be run