- User Since
- Feb 24 2015, 1:18 AM (226 w, 1 d)
- Don't use VRM for VirtReg in analyzeOperands(). In case of an eviction (where VirtReg already has a physreg in VRM), this previous regclass should not be reused initially.
Tue, Jun 18
Here's an updated list of stats for SPEC 2006, with the latest fixes applied, and also with "soft hints" at the bottom.
Don't skip all 2-address hints in getRegallocationHints() just because it's a GRH32 register: AHIMuxK actually can expand to a 2-address instruction using a high register.
Mon, Jun 17
- SystemZSelectMux.cpp merged into SystemZPostRewrite.cpp.
Sat, Jun 8
This test has now been added as int-sub-11.ll by r362868 "Favor 3-address instructions during instruction selection".
Fri, Jun 7
Thanks for review! Committed as r362868.
More multiclasses moved down to new section in SystemZInstrFormats.td
Thu, Jun 6
Move down new multiclasses to new section.
Wed, Jun 5
I did SPEC runs overnight on both 2006 and 2017, see summary-files:
Mon, Jun 3
merged into D60888.
D62803 merged into this patch.
May 16 2019
Thanks for review.
(This patch is NFC on benchmarks).
May 14 2019
There are still no tests failing with this patch, and I do think I have met all requests from reviewers...
May 13 2019
Patch refactored, with very near NFC.
Apr 30 2019
...it is unlikely we can fix this later, since RA will have allocated an additional register to load the spilled value into, and this will have pessimized the whole function (since we must already have register pressure, otherwise we wouldn't have a spilled value in the first place)...
Apr 29 2019
Removing the improvement in foldMemoryOperandImpl().
Apr 26 2019
Well, I wasn't sure how the hinting mechanism iterates. I'd have thought the following might be possible:
First, because of this instruction:560B $r2d = COPY %21:gr64bit
register %r21 is hinted as $r2d.
Because of that, and this instruction:400B %21:gr64bit = AGRK %20:gr64bit, %10:gr64bit, implicit-def dead $cc
we now get a new hint for register %r20 as $r2d
... and so forth backwards through the AGRK chain.
@Quentin: This has the same common-code change as in D58923, with the added VRM to foldMemoryOperand(). You seemed fine with this change, right?
Apr 22 2019
Most points in review inocoorporated, except for the getRegAllocationHints() -- see inlined comment.
Apr 19 2019
Don't build a new MI in selectAddSubMux(), but instead update the registers, MCInstrDesc and TiedTo flag. This avoids the need to update SlotIndexes. This is needed to not loose any extra ("regalloc") operands or instruction flags (such as "nsw") . Question: Are there any such flags that should be modified when commutation is performed on a sub and it becomes an add?
Apr 18 2019
Apr 5 2019
Thank you Quentin for the review! Patch updated per your suggestions. (I am not sure why LIS and VRM are optional parameters to foldMemoryOperandImpl(). It would have simplified my patch somewhat if they were not, but I instead added a check to see that VRM is available.)
Apr 4 2019
Apr 2 2019
Regalloc hints for llc/llh added as well, which handled two regressions.
Mar 27 2019
Thanks for review! Test case updated per suggestion.
Mar 26 2019
Mar 25 2019
Patch refined / improved.
Mar 19 2019
Patch is still experimental, but updated with the latest improvements.
Mar 18 2019
I did something similar for the SystemZ PostRA scheduler. Is this patch taking that into consideration? I have not looked at this in detail, but it would be nice if the SystemZ implementation could use this or at least parts of it...
Mar 16 2019
I think the SystemZ test changes look ok (by replacing the undef operands with an argument the tests are more or less unaffected by this patch), but as usual I will let Uli do the formal approval.
Mar 12 2019
Still INCOMPLETE! SPEC builds, but this patch is still experimental.
Mar 11 2019
Mar 10 2019
Mar 4 2019
The patch as of now is a work in progress (experimental).
Feb 26 2019
Replaced by https://reviews.llvm.org/D58270.
Replaced by https://reviews.llvm.org/D58270.
Thanks for help and review!
Feb 25 2019
I don't think this will make much of a difference compile-time wise, so I'd prefer to go with the version where the code looks simpler ...
I tried this patch on SystemZ / SPEC, and as before this seems to have a relatively very minor impact on the number of files changed (7), and on the performance (seemingly unaffected).
Generally we should prefer to perform combines in DAGCombine in cases where it's straightforward.
Feb 23 2019
Patch updated per review, thanks.
Feb 20 2019
Added handling for fp128 on z14, with some new tests that checks that this is working in fp-const-11.ll. NFC on spec on z14.
Feb 15 2019
Feb 14 2019
Tried this idea, see https://reviews.llvm.org/D58270
Feb 13 2019
Feb 12 2019