similar to: [LLVMdev] Use perf tool for more accurate time measuring on Linux

On 16 May 2014 18:08, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Yi Kong" <kongy.dev at gmail.com> >> To: "Hal Finkel" <hfinkel at anl.gov>, "Renato Golin" <renato.golin at linaro.org>, "Tobias Grosser" <tobias at grosser.es> >> Cc: "LLVM Dev" <llvmdev at

On 16 May 2014 18:40, "Chandler Carruth" <chandlerc at google.com> wrote: > > Why not use the cycle count which perf exposes from hardware? That would seem even better to me, but data would be better. =] That's an interesting idea. However I'm concerned if that will miss some aspects of compiler optimization. For example frequent cache misses would have much smaller

On Thu, May 22, 2014 at 12:09 AM, Tobias Grosser <tobias at grosser.es> wrote: > On 21/05/2014 22:13, Yi Kong wrote: > >> On 20 May 2014 17:55, Tobias Grosser <tobias at grosser.es> wrote: >> >>> I set it to 2667.000 Mhz on parkas16. You can try if this improves >>> something. >>> >> >> I don't see any sign of improvement.

I've set up a public LNT server to show the result of perf stat. There is a huge improvement compared with timeit tool. http://parkas16.inria.fr:8000/ Patch is updated to pin the process to a single core, the readings are even more accurate. It's hard coded to run everything on core 0, so don't run parallel testing with it for now. The tool now depends on Linux perf and schedtool.

On 20 May 2014 16:40, Tobias Grosser <tobias at grosser.es> wrote: > On 20/05/2014 16:01, Yi Kong wrote: >> >> I've set up a public LNT server to show the result of perf stat. There >> is a huge improvement compared with timeit tool. >> http://parkas16.inria.fr:8000/ > > > Hi Yi Kong, > > thanks for testing these changes. > > >> Patch

On 1 August 2014 21:33, Chandler Carruth <chandlerc at google.com> wrote: >> Note, this patch is actually the smaller culprit, around 209801 there is >> another performance regression, but I have no idea if/where this is coming >> from or if this for some reason is a false positive. > > > I'm having to question the results on this bot. The range of commits

On 20 May 2014 17:55, Tobias Grosser <tobias at grosser.es> wrote: > On 20/05/2014 18:20, Yi Kong wrote: >> >> On 20 May 2014 16:40, Tobias Grosser <tobias at grosser.es> wrote: >>> >>> On 20/05/2014 16:01, Yi Kong wrote: >>>> >>>> >>>> I've set up a public LNT server to show the result of perf stat. There

Hi Chandler, On an x86 system, for ToT LLVM: With "Remove support for LLVM runtime multithreading": 23.8788 With patch reverted: 22.5229 That's around 6% regression. Detailed JSON file is at http://paste.debian.net/113238, http://paste.debian.net/113239 -Yi On 1 August 2014 21:56, Chandler Carruth <chandlerc at google.com> wrote: > > On Fri, Aug 1, 2014 at 1:47 PM,

On 20 May 2014 17:55, Tobias Grosser <tobias at grosser.es> wrote: > I set it to 2667.000 Mhz on parkas16. You can try if this improves > something. I don't see any sign of improvement. Since we can't get raw data any better, I think we should get this merged and tested on build bots for a while and see how it goes. Cheers, Yi Kong

After some internal discussions, we concluded that moving non-memory-access and non-side-effect instructions around memory barrier intrinsics is fine in almost any typical situation. In the rare occasions where reordering is undesirable, the programmer should use inline asm instead. Thus I'm dropping this RFC. Thanks for your comments. -Yi

Hi all, I'm currently working on implementing ACLE extensions for ARM. There are some memory barrier intrinsics, i.e.__dsb and __isb that require the compiler not to reorder instructions around their corresponding built-in intrinsics(__builtin_arm_dsb, __builtin_arm_isb), including non-memory-access instructions.[1] This is currently not possible. It is sometimes useful to prevent the

On 2 August 2014 00:40, Renato Golin <renato.golin at linaro.org> wrote: > If memory serves me well (it doesn't), these are the list of things we > agreed on making, and their progress: > > 1. Performance-specific test-suite: a group of specific benchmarks > that should be tracked with the LNT infrastructure. Hal proposed to > look at this, but other people helped

I got Python 2.7.3 Sounds right? On Fri Aug 08 2014 at 4:45:01 PM Yi Kong <kongy.dev at gmail.com> wrote: > Hi Jingyue, > > I've never seen this error before. It looks like something to do with > virtualenv. > > What do you get by running `~/mysandbox/bin/python --version`? > > -Yi > > On 8 August 2014 23:48, Jingyue Wu <jingyue at google.com>

Hi, I followed the instructions on http://llvm.org/docs/lnt/quickstart.html, and got stuck on installation Step 4. ~/mysandbox/bin/python ~/lnt/setup.py develop said running develop error: None and returned error code 1. The lnt binary wasn't installed anywhere. Any clue? Thanks much, Jingyue -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello everyone, I am working to run the LLVM Nightly Testsuite on embedded arm devices. Not all of these devices can mount NFS to share a common directory tree. To mitigate this I have patched test-suite/RunSafely.sh (attached) to create a temporary directory, run the test remotely, collect the output, and cleanup after itself. The patch breaks compatibility with the current remote device model

The issues seems to be this line in the tools Makefile timeit-target: timeit.c $(LD_ENV_OVERRIDES) $(LCC) -o $@ $< $(LDFLAGS) $(CFLAGS) $(TARGET_FLAGS) -O3 It should not add target 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

Hi, I'm trying to setup the test-suite and am getting short of running it... Following the steps here: http://llvm.org/docs/lnt/quickstart.html I got as far as getting lnt installed, but when I run the "lnt runtest nt" it fails: compilers.py:81: error: unable to determine compiler version: 'clang++': 'clang version 3.2 ' Seems my string doesn't have a

I hit the same problems as you did when I tried it a few weeks ago. Haven't bothered with it since. There is a way to run tests without using lnt. You can use the Makefiles directly in your test-suite build directory. For running nightly tests, you can do: make report.html TEST=nightly That will generate a html file with the test results in. Amara On 26 October 2012 22:53, Renato Golin

Hi, I am not sure if this is the right forum. Please direct me to the appropriate place if it isn't so. Please keep in CC as i am not subscribed to this mailing list. I am trying to test riscv llvm tools in QEMU using llvm testsuite. As a trial i am trying only the Single Source C Regression folder. The steps that i took are : ]$ cmake -DCMAKE_C_COMPILER=/opt/riscv-tools/bin/clang

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