- User Since
- Feb 16 2014, 1:10 AM (195 w, 6 d)
Sep 29 2017
Reverted in https://reviews.llvm.org/rL314551.
Reverted in https://reviews.llvm.org/rL314551.
It turns out polly makes use of these variables. I'll revert this for now and try again after taking a closer look at polly.
Thanks @beanz! I'll keep an eye on the bots. Here goes nothing! :)
Sep 28 2017
Sep 27 2017
Great, thanks @beanz! I wanted to make sure I was understanding the terminology :)
Sep 19 2017
Thanks for the improvement!
Sep 13 2017
Aug 30 2017
Added some tests to test/CodeGen/ARM/swifterror.ll, also courtesy of John Holdsworth.
Aug 23 2017
Replace Running member with StartCount.
Aug 22 2017
Use startReentrantTimer and stopReentrantTimer
One downside of separate startReentrantTimer and stopReentrantTimer methods is that we may need to add a bool IsReentrant parameter to the initializer of TimeRegion, in order to support the way it's used in https://reviews.llvm.org/D36946.
Instead of using virtual methods, add Timer::startReentrantTimer and Timer::stopReentrantTimer. @MatzeB, let me know if this isn't what you had in mind -- thanks!
Thanks for the suggestions, @MatzeB! I'll try to get rid of the added vtable.
Aug 21 2017
Friendly ping -- does anyone have any thoughts here?
Aug 19 2017
Aug 18 2017
Aug 17 2017
Aug 16 2017
Friendly ping! I think this is ready to be reviewed. It adds an additional row, Preprocessing, to the Miscellaneous Ungrouped Timers section of the clang -ftime-report output:
Aug 15 2017
Oops, sorry, didn't mean to remove the subscribers. arc diff --verbatim strikes again.
Add PreprocessorOptions::getTimer, and move the timer to the top of Preprocessor::Lex().
Aug 14 2017
Aug 13 2017
Aug 11 2017
I double-checked this diff worked when run on a directory containing a single YAML file, using Python 2, and it appeared to work. Let me know if it breaks anything for any of your workflows!
Hey, no worries! I almost never catch Python 2/3 incompatibilities ahead of time. As I mentioned on PR34129, it'd be great to get some automated testing in place that could catch Python 2/3 errors as well, but until then I'm happy to fix these as I notice them.
Yup, I've confirmed this still works with Python 2. Thanks, @anemet!
Aug 10 2017
Oops, sorry. I couldn't find anyone recent in the commit history. I hope no one minds if I just go ahead and commit this.
Thanks for the feedback, @vsk, I really appreciate it! I have some other work done for this on my local checkout, but I was going a little bonkers working on it without knowing whether people would want it merged or not. I'll update this with your feedback and upload the rest for review as well.
Aug 9 2017
Aug 8 2017
Aug 3 2017
Aug 2 2017
@rnk After this patch, the check-lit target leaves untracked files in the source tree:
Yup, I've tried reverting D36026 locally, and after doing so check-lit no longer dirties my source tree. I'll comment there with next steps. IMHO reverting and then applying the changes you suggested might be a good way to go!
I'm happy either way! I was going to put the patch up for review but I noticed that after running some lit tests there appear to be some artifacts being created and left over outside of the build directory.
Apologies for jumping in on your patch here.
Aug 1 2017
Jul 29 2017
Jul 27 2017
This Windows buildbot failure could potentially be related: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/4046. The build failed due to a timeout. That being said, the bot *is* named "expensive-checks", so maybe a timeout is to be expected...? I'll keep monitoring builds for now.
Yup! Sorry for the wait. This works for me! :)
I am definitely a fan of turning these on first, then optimizing to reduce the time it takes for them to run. For the record, with this patch applied locally, check-all takes 681.54 real, 3349.92 user, 614.90 sys, whereas before it took 667.35 real, 3293.70 user, 600.09 sys. I hope that's acceptable price to pay for keeping lit's own tests passing, at least until we can optimize it to run faster.
Update commit message
I sent up D35947 to fix the new failures. Then I think I'll try to land this and get lit tests running continuously, unless anyone has any objections. :)
Hmm, when run locally on my macOS, max-failures.py and shtest-shell.py are now failing, so those will definitely need to be fixed before this is landed. I'm on rL309282.
An easy way to reproduce:./utils/lit/lit.py -v utils/lit/tests/max-failures.py utils/lit/tests/shtest-shell.py
The equivalent of this change was committed by @rnk in rL309200. I slightly prefer this change because the version of Python that is currently running is used to execute the shell tests, whereas rL309200 may use Python 3 to run the tests, but shell out to Python 2.
The equivalent of this change was committed by @rnk in rL309194. I sort of prefer this because it verifies the same separator is used throughout, instead of accepting either. But either way works for me!
Jul 26 2017
LGTM, but I want to double-check this passes for me locally. Also, I think you may have left some debugging code in here.
Just FYI, test/Other/new-pm-pgo.ll appears to be failing on several of the buildbots. One example: http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/10801