- User Since
- Sep 30 2018, 2:53 PM (46 w, 1 d)
Fri, Aug 16
Wed, Aug 14
Tue, Aug 13
Fri, Aug 9
~/llvm/test-suite/utils/compare.py --filter-short -m exec_time ~/llvm/test-suite-results/results_rel_base.json ~/llvm/test-suite-results/results_rel_base2.json vs ~/llvm/test-suite-results/results_rel_exp.json ~/llvm/test-suite-results/results_rel_exp2.json
Tue, Aug 6
Wed, Jul 31
Wed, Jul 24
Hi @lebedev.ri, could you please lgtm this or elaborate on possible issue with this?
Remove default repeat
Hi all! Could it be accepted or reviewed more?
Tue, Jul 23
Jul 19 2019
Btw, this fix (https://reviews.llvm.org/D64394) was commited recently.
Jul 18 2019
Hi all! I've figured out that my current implementation of PRE is incorrect and it needs to be either corrected, restricted or reverted.
The issue is that current PRE can actually hoist instruction executing it speculatively for some CFG paths which potentially leads to perf degradation. However I believe that current heuristic PRE is rather useful if it is restricted enough. Good restriction (apart from this revision) is implemented by @lkail here: https://reviews.llvm.org/D64394, it is based on basic block frequencies comparision.
Btw, this change breaks multiple (more than two) hoisting to common dominator. I've tested this patch for the original test case taken from here: https://bugs.llvm.org/show_bug.cgi?id=38917. There are several comparisons giving 96 > 40 + 10, 96 > 29 + 10, 96 > 18 + 10 (so no hoisting at all), meanwhile 96 < 97 = 40 + 29 + 18 + 10.
However I do not see easy solution for this issue.
Jul 16 2019
Jul 14 2019
Jul 10 2019
Jul 9 2019
Jul 8 2019
Add small fix
Hi @piotr, have you tried regression benchmarking with this patch? For instance, test suite.
Jul 5 2019
This patch fixes https://llvm.org/pr42405 implicitly.
Jul 4 2019
I've upload json-file and printscreen of its visualization (used https://speedscope.app). This is an example of how this patch works, making two Frontend sections.
Jun 28 2019
Is it ok now? I doubt that main code refactoring is a good way when adding support timer code. So ended with more robust solution, though it leads to two Frontend sections.
Jun 26 2019
Jun 24 2019
Jun 23 2019
Jun 21 2019
Also, first "Frontend" section contains "ParseTemplate" and "PerformPendingInstantiations" sections.
Hi @lebedev.ri, I've turned back to the solution with one TimeTraceScope for "Frontend" inside BackendConsumer::HandleTranslationUnit(), since it looks more robust. This admits several (two for now) "Frontend" sections, but I see no problem with this. Other solutions have to rely on BackendConsumer and ASTConsumer calling correct relations, which are not guaranteed (though it is looking correct for now).
Jun 19 2019
Updated, changed test
Jun 18 2019
Jun 14 2019
Jun 12 2019
Last issue fixed by this revision: https://reviews.llvm.org/D63148
Jun 11 2019
The issue actually is not with this instruction, but it's related to exception handling. Hoisted instruction is inserted before getFirstTerminator(), but there could be EH_LABEL's which are not terminators, but could change control flow.
Jun 9 2019
Closed by commit https://reviews.llvm.org/rL362901
Jun 7 2019