- User Since
- Jul 18 2018, 9:45 PM (244 w, 4 d)
Oct 11 2019
Oct 10 2019
update test case
Oct 9 2019
add ; REQUIRES: asserts for test case
Oct 8 2019
Oct 7 2019
Add more comments and rebase to up-to-date.
I'd like to upstream it first, and interface modification would be done in follow-up patches.
Oct 1 2019
Sep 29 2019
Rebase it and rerun bmk 2017 to make last check before launch.
Sep 27 2019
We can land it firstly and update the interface to use MVT as simplest type to getRegisterClassForType parameter and call TLI->getTypeLegalizationCost before.
This can apply to where GetRegUsage works
update the comment of getRegisterClassForType. Make it landed firstly and update the interface to leverage MVT in follow-up work.
Sep 26 2019
Sep 23 2019
Sep 18 2019
Sep 17 2019
Add some comments at function interface prototype.
Sep 16 2019
Change the interface prototype of getRegisterClassForType and make second parameter with default value.
Sep 15 2019
Address comments to simplify the default implementation for targets.
Sep 12 2019
Address comments. Add 3 function interfaces.
Sep 10 2019
Sep 9 2019
Sep 5 2019
Sep 4 2019
Sep 3 2019
Sep 2 2019
Aug 26 2019
Could anybody run some bmk to see the performance result of AARCH64 and X86?
I have run on PowerPC, it has good influence in some bmks of spec2017 and no obvious degression.
Enable it for AARCH64 and x86, and address testcases.
Aug 25 2019
Aug 22 2019
This is a WIP draft and I have not fixed all check-all cases now. I want to get some quick feedback whether it's on the right direction and whether its performance is good at all different target. If you have time, could you please review it or give some comments, and help me to verify the performance at other targets?
Aug 15 2019
Aug 14 2019
Is there any fix patch proposed to track/fix the regression? @dnsampaio
Aug 12 2019
Aug 8 2019
Should this good patch be rebased and continued to move on? @wmi
it'd be better to move on this work because D27366 is abandoned and D34608 is not updated for a long time, and those 3 patches are all trying to fix same issue and not landed successfully.
It would be great If it can land.
Aug 5 2019
Aug 4 2019
Should this be rebased and continued to move on? Or it already could be addressed by https://reviews.llvm.org/D41765? @junbuml @qcolombet
Jul 31 2019
Because we have PPCVSXSwapRemoval pass to hack the element order before P9 with vsx, the element order is not always standard normal order in register.
And the optimization of this patch will be conflict with PPCVSXSwapRemoval so that we can not get correct result during the process. The fix way is to not do this optmization before P9.
update patch due to find issue.
Jul 30 2019
Sorry to forget to add revision address in commit. Close it manually.
Jul 29 2019
Commit testcase firstly and address comments.
Jul 26 2019
Jul 25 2019
Jul 24 2019
Jul 22 2019
Jul 21 2019
Jul 17 2019
After run bmk 2017 cpu for fortran and c/c++, there is some noise, no obvious degression. Some have little improvement about 1%~2%.
Jul 16 2019
Jul 15 2019
gentle pin... It's a follow-up of https://reviews.llvm.org/D60601
Jul 4 2019
Jul 3 2019
Jul 1 2019