Aug 5 2020
Jun 11 2020
The way I see it, with size level for LTO, we could have a different LTO optimization pipeline for size or runtime performance. For example, we could have a different tuning for inlining, vectorization, etc. We could also use the size level to automatically enable optimizations such as HotColdSplitting, MergeFunctions, etc., instead of relying on specific enabling flags. We could also have other size-specific optimizations in the future, such as MergeSimilarFunctions (https://reviews.llvm.org/D52896).
Jun 5 2020
If reviewers think that this patch is touching in too many files, I could try to focus it only on the LTO related files, converting OptimizationLevel back to two separate values when necessary.
LLVM already has the class PassBuilder::OptimizationLevel that encapsulates the logic of both speed and size optimization levels. This class already checks which values for SpeedLevel and SizeLevel are valid.
Jun 4 2020
Dec 7 2019
Nov 24 2019
Nov 7 2019
Simplified test case.
Added test case that exercises this issue.
Oct 1 2019
Thanks everyone for your comments.
Addressed @fhahn 's comment.
Indeed. That's much better.
Addressed @fhahn 's comments.
Sep 30 2019
This the same patch after running clang-format specifically to the llvm::removeUnreachableBlocks() function.
I have fused two loops. Now, for any execution path, only two loops over DeadBlockSet will be performed, instead of the previous worst-case of three loops.
Sep 29 2019
Jun 28 2019
Just a very minor thing.
Mar 19 2019
I understand your point of having a light-weight function merging (FM) to leave always on to reduce code-size/compilation-time.
I agree that perhaps we could have a parametrized merger that enables/disables more powerful comparisons.
That's why I also suggested that a more powerful merger (like my FM by Sequence Alignment) could be only enabled for heavier code-size optimizations (like -Oz) and have a light-weight FM always enabled (or enabled for most of the optimization settings).
Mar 15 2019
This example that I gave in my comment is a simplistic one that gets canonicalized.
However, this patch would handle more interesting examples as well. Such as the following one:
Nov 18 2018
Can someone please commit this patch for me because I believe I don't have commit access.
Nov 17 2018
Sep 24 2018
I've rebased to the patch and changed the name of the unit-test UnrollLoop.cpp to UnrollLoopTest.cpp, similar to the other files in the same folder.
Sep 12 2018
I'd like to confirm that someone can commit this patch for me because I believe I don't have commit access.
Sep 5 2018
I've added the test requirement, as suggested.
I've added the unit-test.
Thanks for the suggestion and the unit-test code. I'll add it to the patch.
Sep 4 2018
I think that this patch is mainly important because these functions are externally visible in the library's API.
In fact, I experienced this problem when using the function llvm::UnrollRuntimeLoopRemainder in one of my own passes and then running it on SPEC2006.
This patch avoids unnecessarily making an implicit contract with the API's user.
Aug 30 2018
I completely agree with your assessment.
Sorry, I'll make sure to upload with a full context in the next time.
Aug 2 2018
Jul 31 2018
I have fixed the bug that this patch was producing on Polly.
Jul 12 2018
It will need to be synchronised with the merge of the other patch.
Otherwise, the other patch would break Polly.
Jul 10 2018
I've fixed the graph printing in Polly.
Jun 29 2018
I've just noticed that last time I uploaded the wrong diff.
Jun 26 2018
Minor update to avoid conflict with the latest LLVM release.
Jan 19 2018
I kept the print functions as they were already present in the code and this change is not related to the heat colors.
Dec 4 2017
Fix remaining code-style standards and option descriptions.
Fix small code-style standards.
Dec 2 2017
Fixed function getNumOfCalls for both full and simplified visualization of the call-graph.
Dec 1 2017
Updates the CFGPrinters to work on a per-module basis.
Nov 28 2017
Changes regarding @davidxl comments.
Nov 24 2017
Some code refactoring was performed, for example, replacing data structures from the C++ STL to equivalent one in LLVM ADT.
Closed due to incorrect configuration.
Another revision will be opened with the correct configuration.