- User Since
- Jul 4 2017, 1:39 AM (93 w, 4 d)
Thu, Apr 18
Tue, Apr 16
added more test checks to trivial-unswitch.ll to cover all new and changed code
rebased to the latest D60544 and formatted
Mon, Apr 15
I would split this change into NFC and last-call-to-static.
- removed 2 tests fixes into a separate patch
- changed branch weight sum type to uint64_t
- extracted separate method getProfBranchWeightsMD() that is used in the dependent patche
Yes. But I believe that the fix would be unrelated to this patch. I do not see any way to fix branch_weights for partially unswitched branch instruction other than to drop the prof branch_weights metadata.
Philip, as I see in the doc https://llvm.org/docs/BranchWeightMetadata.html#supported-instructions there are only 4 instructions allowed to have prof branch_weights: BranchInst, SwitchInst, IndirectBrInst and CallInst. CallInst is not a terminator instruction.
I'm proposing API changes for SwitchInst only. Very similar changes can be done to IndirectBrInst.
BranchInst and CallInst have fixed num of branch weight params so they do not need the changes in add/remove methods.
If you agree, I will prepare similar changes for all 4 instructions or just 2 (SwitchInst and IndirectBrInst).
The logic behind these changes is the following. I'd like to keep the prof branch_weights metadata to be kept correct through all passes that do not care about metadata and I do not want to change those passes. They add successors without specifying branch weights and remove successors disregarding the metadata consistency. On the other hand passes can explicitly specify the branch weights along with changed successors.
Fri, Apr 12
fixed test llvm/test/Transforms/SimpleLoopUnswitch/trivial-unswitch.ll
Thu, Apr 11
Feb 3 2019
Feb 1 2019
Jan 31 2019
Jan 28 2019
- added a simple test
- changed implicit conversion to char* to explicit field access IsViable.message
Jan 25 2019
Jan 24 2019
addressed all comments
Jan 23 2019
Oct 28 2018
- ~Destructible() moved to cpp file
- changed pthread to std::thread in the test
- added GetThreadOptionContext() and ThreadOptionContext is made protected
Oct 25 2018
The RFC can be found here http://lists.llvm.org/pipermail/llvm-dev/2018-October/127039.html
Oct 24 2018
Oct 23 2018
Frankly speaking, I do not think that this kind of transition can be done easily. Every single option needs a big change. That is the biggest disadvantage of the feature D5389. It needs some improvements to allow enough flexibility. And we cannot know what improvements are needed until we implement enough options in the new way. I do not see any good way to force the transition to finish in a fixed time frame. If D5389 were easy to use and transit to, it would have been already adopted and we would not have to came up with another idea like this D53424.
In other words, I would give the new idea a try (at least under a preprocessor flag).
This is a very good summary. I would suggest that we land this patch and mark this feature as a temporary solution asking the users to consider moving the options they redefine to the new API D5389.
Oct 22 2018
LLVMContext is not always created when cl::opts are used. In other words, I intentionally made the use of this new feature (the thread local option context) wider than the scope of LLVMContext. Users can bind they LLVMContexts to the thread local option context as they needed. It can be done by creating a ContextValue along with LLVMContext and setting this ContextValues as the thread local option context for all threads that work with the LLVMContext instance.
I did not understand your point about collection a list of cl::opts. I do not collect any lists. Instead, every thread local option context collects only those options that have been redefined for this context.
Oct 19 2018
Sep 17 2018
Component owners, please take a look or suggest someone who can review.
Aug 31 2018
Thank you Dávid for your help.
Aug 29 2018
Any thoughts? Ideas?
Aug 27 2018
ninja check-all passed except one test failure Clang :: Modules/prune.m.
It seems to be unrelated to this patch as it is reproducible with clean master sources.
Aug 26 2018
Fixed build failure by moving operator<<(std::basic_ostream<char> &R, const ore::NV &Arg) out of #ifndef NDEBUG condition.
Started ninja check-all for non-debug config.
Aug 24 2018
make check-all passed.
Re-checking is in progress. I'm almost sure it will pass as inline-remark-attribute is set to false by default.
Aug 22 2018
- added cl:desc to inline-remark-attribute option
- changed return type of InlineCallIfPossible() from bool to InlineResult
- added one more test to see InlineResult printed in inline-remark attribute
- reformatted body of function setInlineRemark()
Aug 17 2018
I will address all comments by the end of the next week.
Aug 12 2018
fixed the test: removed extra whitespaces, changed description of Test1
Aug 8 2018
Aug 5 2018
Thank you very much, Dávid!
Aug 3 2018
Aug 1 2018
The fixes seem to be simple, but I need to set up and build additional projects.
How can I submit patches to several projects that should be synchronously updated?
Jul 31 2018
Fixed the buildbot failure (clang++ compilation error) by putting the operator<<(.., NV &Arg) before the template operator<<(.., InlineCost) in Inliner.cpp.
Started looking at the failure.
Jul 30 2018
I have just made checked with the latest trunk.
Committers! could anyone land this patch please?
Jul 29 2018
Minor change: got got rid of multiple string operators += in inlineCostStr() by reusing the output stream template for printing InlineCost.
Jul 27 2018
- moved InlineResult from Cloning.h to InlineCost.h
- changed InlineCost printing to (cost=X, threshold=Y) or (cost=never): message or (cost=always): message. Had to fix many test checks.
Jul 19 2018
Updated delimiters in output as requested.
Jul 18 2018
Jul 16 2018
Jun 25 2018
the landed patch D47441 supersedes this one.
Jun 22 2018
Removed a separate analysis pass - CFGDeadness is made internal.
Jun 19 2018
LLVM committers, this patch seems to be ready for landing, please.
Jun 18 2018
Added Artur's comment.
Jun 9 2018
previous diff was incorrect, please ignore it.
In this diff I removed CFGDeadness::processInstruction() and changed to iterate over the block terminators.
Removed CFGDeadness::processInstruction() and changed to iterate over the block terminators.
Jun 8 2018
Addressed Anna's comments:
- changed INITIALIZE_PASS CFGDeadness CFG flag to false.
- The new method CFGDeadness::hasLiveIncomingEdge(Phi, Block) replaces CFGDeadness::getIncomingEdge(Phi, Block) that could not work with phi containing duplicate pairs of (value,block).
Jun 5 2018
Please review the patch.
Anna, Daniil, you are the best candidates for reviewing the patch.
Jun 4 2018
Added dead edge definition and appropriate assertions to the method isDeadEdge().
Inlined the method processFoldableCondBr() into processInstruction().
Jun 1 2018
Addressed Anna's comments: extracted a separate analysis pass called CFG Deadness.
May 29 2018
Added test cases with a dead edge but without dead blocks.
Fixed the algorithm to ignore such dead edges.
May 28 2018
I realized that there is a case with a dead edge but without dead blocks. I will improve the patch and add a testcase.