search for: ddunbar

Nice! This looks good to me but probably Chris or someone else should sign off on it. There were two minor warnings on Darwin: -- In file included from /Volumes/Data/Users/ddunbar/llvm/lib/Support/regexec.c:81: /Volumes/Data/Users/ddunbar/llvm/lib/Support/regengine.inc: In function 'sbackref': /Volumes/Data/Users/ddunbar/llvm/lib/Support/regengine.inc:665: warning: control reaches end of non-void function In file included from /Volumes/Data/Users/ddunbar/llvm/lib/Sup...

...main problem I have > with the rest of this patch is that it causes a regression in > llvm-prof's behavior. I tried running edge profiling on the > MultiSource/Applications/aha benchmark in the llvm test-suite, and > llvm-prof no longer prints any function information: > -- > ddunbar at giles:aha$ opt -f Output/aha.linked.rbc -insert-edge-profiling -o foo.bc > ddunbar at giles:aha$ llc foo.bc -o - | gcc -x assembler - -x none > ~/llvm/Debug/lib/profile_rt.dylib > ddunbar at giles:aha$ ./a.out > ... > ddunbar at giles:aha$ ~/llvm/Release/bin/llvm-prof foo.bc llvmp...

..._main" only (this subsumes -fvisibility-inlines-hidden). These are all Release builds. empty.ll is in fact empty, empty.bc is the resultant .bc, and empty.c has one int variable. runN is a program which simply fork-execs the given program N times (1000 in this case). ===== # For a baseline: ddunbar at ddunbar2:rt$ time runN 1000 `which true` real 0m1.561s user 0m0.303s sys 0m1.136s --- clang --- # 4152 weak external & defined symbols ddunbar at ddunbar2:rt$ time runN 1000 ./clang-cur empty.c real 0m8.398s user 0m4.708s sys 0m3.299s # 1937 weak external & defined s...

On 2009-08-27 09:06, Daniel Dunbar wrote: > 2009/8/25 Török Edwin <edwintorok at gmail.com>: > >> On 2009-08-25 21:18, Daniel Dunbar wrote: >> >>> Woot! Thanks a bunch Edwin! >>> >>> Some comments on the patch: >>> -- >>> I'm not sure if it makes sense to import the man pages, if we only >>> expose Regex.h.

...;> with the rest of this patch is that it causes a regression in >> llvm-prof's behavior. I tried running edge profiling on the >> MultiSource/Applications/aha benchmark in the llvm test-suite, and >> llvm-prof no longer prints any function information: >> -- >> ddunbar at giles:aha$ opt -f Output/aha.linked.rbc -insert-edge-profiling -o foo.bc >> ddunbar at giles:aha$ llc foo.bc -o - | gcc -x assembler - -x none >> ~/llvm/Debug/lib/profile_rt.dylib >> ddunbar at giles:aha$ ./a.out >> ... >> ddunbar at giles:aha$ ~/llvm/Release/bin/ll...

...;> with the rest of this patch is that it causes a regression in >> llvm-prof's behavior. I tried running edge profiling on the >> MultiSource/Applications/aha benchmark in the llvm test-suite, and >> llvm-prof no longer prints any function information: >> -- >> ddunbar at giles:aha$ opt -f Output/aha.linked.rbc -insert-edge-profiling -o foo.bc >> ddunbar at giles:aha$ llc foo.bc -o - | gcc -x assembler - -x none >> ~/llvm/Debug/lib/profile_rt.dylib >> ddunbar at giles:aha$ ./a.out >> ... >> ddunbar at giles:aha$ ~/llvm/Release/bin/ll...

On Feb 25, 2011, at 11:38 AM, Rafael Avila de Espindola wrote: >>> Can someone else try to reproduce this? > > I tried gcc.c from > http://people.csail.mit.edu/smcc/projects/single-file-programs/ and the > difference is a bit more noticeable: > > -O0 -mno-relax-all > > real 0m13.182s > user 0m12.690s > sys 0m0.450s > > -O0 > > gcc.o is

...of this patch is that it causes a regression in >>> llvm-prof's behavior. I tried running edge profiling on the >>> MultiSource/Applications/aha benchmark in the llvm test-suite, and >>> llvm-prof no longer prints any function information: >>> -- >>> ddunbar at giles:aha$ opt -f Output/aha.linked.rbc -insert-edge-profiling -o foo.bc >>> ddunbar at giles:aha$ llc foo.bc -o - | gcc -x assembler - -x none >>> ~/llvm/Debug/lib/profile_rt.dylib >>> ddunbar at giles:aha$ ./a.out >>> ... >>> ddunbar at giles:aha$ ~...

Hi all, Thought this might be of general interest, I hacked up the pybugz tool to work with llvm.org. It's here if you want it: http://t1.minormatter.com/~ddunbar/pybugz-llvm-0.7.3.tgz Unpack somewhere, and make a link to the 'bugz' script. Usage: -- ddunbar at ozzy-2:~$ bugz get 1000 * Using http://llvm.org/bugs/ * Getting bug 1000 .. Title : Chris Is Buggy Assignee : tonic at nondot.org ... ddunbar at ozzy-2:~$ bugz search foo * Using...

2009/8/25 Török Edwin <edwintorok at gmail.com>: > On 2009-08-25 21:18, Daniel Dunbar wrote: >> Woot! Thanks a bunch Edwin! >> >> Some comments on the patch: >> -- >> I'm not sure if it makes sense to import the man pages, if we only >> expose Regex.h. >> > > I'd like to keep re_format.7, it describes the format of the regex as >

...of this patch is that it causes a regression in >>> llvm-prof's behavior. I tried running edge profiling on the >>> MultiSource/Applications/aha benchmark in the llvm test-suite, and >>> llvm-prof no longer prints any function information: >>> -- >>> ddunbar at giles:aha$ opt -f Output/aha.linked.rbc -insert-edge-profiling -o foo.bc >>> ddunbar at giles:aha$ llc foo.bc -o - | gcc -x assembler - -x none >>> ~/llvm/Debug/lib/profile_rt.dylib >>> ddunbar at giles:aha$ ./a.out >>> ... >>> ddunbar at giles:aha$ ~...

>> Can someone else try to reproduce this? I tried gcc.c from http://people.csail.mit.edu/smcc/projects/single-file-programs/ and the difference is a bit more noticeable: -O0 -mno-relax-all real 0m13.182s user 0m12.690s sys 0m0.450s -O0 gcc.o is 10932968 bytes. real 0m12.969s user 0m12.520s sys 0m0.410s gcc.o is 11410552 bytes IMHO it would still be reasonable to switch to

...some missed merge errors. The main problem I have with the rest of this patch is that it causes a regression in llvm-prof's behavior. I tried running edge profiling on the MultiSource/Applications/aha benchmark in the llvm test-suite, and llvm-prof no longer prints any function information: -- ddunbar at giles:aha$ opt -f Output/aha.linked.rbc -insert-edge-profiling -o foo.bc ddunbar at giles:aha$ llc foo.bc -o - | gcc -x assembler - -x none ~/llvm/Debug/lib/profile_rt.dylib ddunbar at giles:aha$ ./a.out ... ddunbar at giles:aha$ ~/llvm/Release/bin/llvm-prof foo.bc llvmprof.out WARNING: profile...

...ses I realized the xfail=[] parameter of getLNTFactor is ignored. Previously this was not an issue, as LNT would automatically XFAIL test cases that failed in the previous run, but it seems Daniel removed this 'feature' a year ago: commit 11987a4615f2a751c30ad6de29e1c277446a940c Author: ddunbar <ddunbar at 91177308-0d34-0410-b5e6-96231b3b80d8> Date: Fri Oct 26 18:52:03 2012 +0000 lnt runtest: Don't use XFAIL just because a test was previously failing. Does anyone know what is the canonical way to mark xfailures when running nightly tests on the buildbots? Should I sw...

Hi, this is the first in a series of patches to cleanup and improve the LLVM Profiling Infrastructure. First and foremost this patch removes duplicate functionality from ProfileInfoLoader and ProfileInfo: The ProfileInfoLoader performed not only the loading of the profile information but also some synthesis of block and function execution counts from edge profiling information. Since the

...t it causes a regression in >>>> llvm-prof's behavior. I tried running edge profiling on the >>>> MultiSource/Applications/aha benchmark in the llvm test-suite, and >>>> llvm-prof no longer prints any function information: >>>> -- >>>> ddunbar at giles:aha$ opt -f Output/aha.linked.rbc -insert-edge-profiling >>>> -o foo.bc >>>> ddunbar at giles:aha$ llc foo.bc -o - | gcc -x assembler - -x none >>>> ~/llvm/Debug/lib/profile_rt.dylib >>>> ddunbar at giles:aha$ ./a.out >>>> ... &gt...

...immediate syntax error). Since 2.4 doesn't support `from __future__ import print_function`, the only alternative I guess is shimming in a print function. This is a maintenance effort that I don't want to do right now (and, TBQH, I feel that the proper maintainer should be responsible for). ddunbar, how does this weight against your "causing large problems with the code" criterion for supporting older versions? As I believe that you are the author and maintainer of lit, are you planning on fixing this compatibility problem? -- Sean Silva On Tue, Dec 4, 2012 at 8:59 AM, Sean Silva...

Hi all, I ran some gcov numbers today for LLVM/clang on their respective test suites (on Darwin/i386). If you are interested, the results are here: http://t1.minormatter.com/~ddunbar/llvm-cov/ and here: http://t1.minormatter.com/~ddunbar/llvm-cov/clang.html High level summary is LLVM's test suite is at 70% line coverage (and that is only the tools that are run) and clang is at 80%. - Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL:...

...> Heh, I think you misunderstood my reply ;-) > > I understand what 'ping' means, I was simply asking Daniel if he has had > chance to deal with this yet. Daniel was out on vacation last week but should be back tomorrow. It's probably best to pin him down on irc, he's ddunbar there :) -Chris

...Since 2.4 doesn't support `from __future__ import print_function`, the > only alternative I guess is shimming in a print function. This is a > maintenance effort that I don't want to do right now (and, TBQH, I > feel that the proper maintainer should be responsible for). > > ddunbar, how does this weight against your "causing large problems > with the code" criterion for supporting older versions? As I believe > that you are the author and maintainer of lit, are you planning on > fixing this compatibility problem? > > -- Sean Silva > > On Tue, De...