- User Since
- Sep 26 2016, 7:58 AM (86 w, 4 d)
Tue, May 22
Mon, May 21
Updated according to suggestions from @mzolotukhin.
Thanks for the review (I'll push this tomorrow when I can observe the build bots).
Thu, May 17
Wed, May 16
Thanks Eli. Definitely a cleaner solution when using a DenseMap.
Replaced the unordered_map by a DenseMap.
So the patch has been confirmed to solve the PR (thanks @uabelho).
But still no ready-to-land. Well I think that I'll land this anyway tomorrow, to get rid of the bug.
Mon, May 14
Fri, May 11
Thu, May 10
Nice, I was looking for something like this when updating MergedLoadStoreMotion.cpp.
Wed, May 9
Tue, May 8
Thanks alot, that was a quick review!
(I'll land this tomorrow when I have time to monitor the buildbots)
Mon, May 7
Simplified the solution, assuming that it is ok to leave some unused PHI nodes behind, at least if the input contains unreachable basic blocks.
Fri, May 4
With the new test case the method formLCSSAForInstructions is invoked three times (three loops?).
Updated the test case (elimintated more branches/blocks, renamed variables/labels, removed checks).
Thu, May 3
Rebased after rL331464
Updated to handle more situations (when the original fragment is so small, so we do not even need to use all parts of the split phi node).
Since we now need to be aware about the size of the old fragment at the call to createFragmentExpression I decided to adjust the size already at the caller and not inside createFragmentExpression.
Just a minor change to enhance readability.
Wed, May 2
Tue, May 1
Some updates suggested by vsk:
- Use zip_first.
- Add a RegsForValue::occupiesMultipleRegisters() helper.
- Cleanup in the test case (removing tbaa and lifetime stuff).
Mon, Apr 30
Fri, Apr 27
As far as I can see this is another case of reusing existing Instructions/Values, while changing the actual value that the Instruction produce, right?
Thu, Apr 26
Apr 25 2018
Apr 24 2018
Thanks Adrian! Updated according to your suggestion and this should be more correct.
Apr 23 2018
buildbots have been failing all day (and were still failing). So I pushed my suggested fix.
I hope that was OK.
I can't see that it has been reverted.
But I guess that the table maybe is sorted based on time spent in each pass? So that is why it might be sorted differently on different buildbots (or when using pipe etc).