- User Since
- Mar 5 2014, 4:23 PM (220 w, 3 d)
Thu, May 17
Wed, May 16
Thu, May 10
Merged with https://reviews.llvm.org/D30268
Thu, May 3
Wed, May 2
Apr 26 2018
My testcase got fixed just with https://reviews.llvm.org/D45926. I'm wondering if this patch is still a good idea.
Comments for enum
This is not in trunk I guess, I borrowed this pass from: https://reviews.llvm.org/D22051
It appears this warning may not be always useful because there will be false positives.
Apr 23 2018
Apr 22 2018
Apr 21 2018
Apr 19 2018
The bug which motivated this warning is: https://github.com/jemalloc/jemalloc/commit/4df483f0fd76a64e116b1c4f316f8b941078114d#diff-7b26b977303fe92c093a2245b0eaf255
Apr 17 2018
Warn on bool* to bool conversion during a call only.
Apr 16 2018
I'll probably make this warning for function arguments only (when bool* is passed to a function accepting bool). Many conditionals use bool* -> bool conversion as pointed out by @Quuxplusone and @aaron.ballman
Apr 12 2018
Mar 9 2018
If you want to update using DJ-Graphs and merge sets, I have implemented them in the global-scheduler which I thought could be reused: https://reviews.llvm.org/D32140
Please let me know if you find this useful.
Jan 3 2018
Dec 20 2017
Dec 13 2017
Dec 5 2017
Nov 10 2017
Nov 9 2017
Added a testcase for irreducible control flow.
Nov 7 2017
Oct 27 2017
Sep 12 2017
Sep 8 2017
added auto to relevant places.
Sep 7 2017
Sep 6 2017
use any_of instead of iterating over the successors.
Aug 23 2017
Addressed @dberlin 's comments.
Agreed, we will evaluate if we can this pass as a utility for vectorizer. In the past we tried that but got stuck because we were unable to recompute loop-access-info once the instructions have been reordered. Maybe you can help us here.
Aug 21 2017
Updated MemorySSA updates.
Outlined functions from codegen part.
Aug 20 2017
Results with the patch.
Aug 17 2017
Aug 15 2017
Aug 11 2017
Remove dead comments.
Aug 10 2017
Based on suggestions from @dberlin, I have updated the patch:
- Compute iterated post-dominance frontiers
- Iterate on post-dominator tree to insert CHIargs more efficiently
Aug 7 2017
@hfinkel , I'd appreciate your feedback, and suggestions for improvement.
Aug 3 2017
Aug 2 2017
For some reason phabricator missed the following comments:
Aug 1 2017
Such a mapping is by definition n^2 space, and i'm having trouble seeing why it is necessary.
Here is what you are doing:
For each instruction with the same VN:find the post-dominance frontier of the block of the instruction Insert a chi there, with certain arguments.
This is unnecessarily wasteful (you may compute the same pdf again and again).
Here is what SSUPRE (and you), should do:
Collect all the blocks of the instructions with the same VN into defining blocks.
Compute the PDF using IDFCalculator.
Place empty chis in the PDF.
At this point, you have two options:Walk post-dominator tree top-down and use a stack to store the last value you see. When you hit a chi from a given edge, the value to use as the argument is at the top of the stack.
This is O(Basic Blocks)
Jul 27 2017
Jul 26 2017
Jul 6 2017
Jun 30 2017
Jun 28 2017
Jun 14 2017
Addressed comments from Eric.
Jun 12 2017
@mzolotukhin Please let me know if you have any further comments.
Jun 9 2017
Jun 7 2017
May 26 2017
When SSAPRE inserts PHI (expression PHIs), it does so at places where (potentially) multiple expressions may merge. If a PHI has a bottom (⊥) entry, that means the expression is partially available.
The concept may work for GVN-Hoist to help factor out anticipability by working on inverted graph. If we insert an outgoing PHI (if I may), to a basic block with multiple successors, as instructions are hoisted upwards to a nearest common dominator.
And we start walking the CFG to figure out if any outgoing PHI has a ⊥, that means the expression is not anticipable in the basic block having that outgoing PHI.
To minimize the number of outgoing PHIs, we will only insert them for expressions with multiple occurrences.
This will help remove the need to check for reachability.
May 23 2017
May 18 2017
May 11 2017
Adding ':' for basic block labels in the testcase
May 10 2017
Addressed @chandlerc 's comments: Essentially, I've added test cases for cycles due to direct branches, indirect branches and invoke instructions.
May 8 2017
I'll add more tests which will reflect different aspects of cyclic control flow. I was trying to explain what program points handle specific cases pointed by you. It will be good if you can suggest any resources which can help create a variety of CFGs.
The code checks for cycle, not loops so it can detect all kinds of explicit cycles as different from other three you mentioned.