In https://reviews.llvm.org/D67148, we use isFloatTy to test floating
point type, otherwise we return GPRRC.
So 'double' will be classified as GPRRC, which is not accurate.
This patch generate different RC for other floating point types.
Differential D71946
[PowerPC][LoopVectorize] Extend getRegisterClassForType to consider double and other floating point type jsji on Dec 27 2019, 12:47 PM. Authored by
Details
In https://reviews.llvm.org/D67148, we use isFloatTy to test floating This patch generate different RC for other floating point types.
Diff Detail
Event TimelineComment Actions Unit tests: pass. 61132 tests passed, 0 failed and 728 were skipped. clang-tidy: pass. clang-format: pass. Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml
Comment Actions Unit tests: pass. 61144 tests passed, 0 failed and 728 were skipped. clang-tidy: pass. clang-format: pass. Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml Comment Actions LGTM but maybe give the original author a day or two to have a look as well before committing. Comment Actions Unit tests: pass. 61237 tests passed, 0 failed and 729 were skipped. clang-tidy: pass. clang-format: pass. Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml |
It seems perfectly reasonable that we want to return VSX/FPR for f32 and f64 types. However, it is not clear to me what we want to do for ppc_fp128, f128, f16, etc.
Don't get me wrong, I think the existing implementation is definitely wrong, I am just wondering if this is a complete solution.