We can decide whether to expand isel or not in instruction selection pass and early-if-conversion pass. The transformation implemented in PPCExpandISel can be retired considering PPC backend doesn't generate `isel` instructions post-RA. Also if we are seeking performant branch-or-isel decision, we can turn to selectoptimize pass. --------- Co-authored-by: Kai Luo <lkail@cn.ibm.com>
The LIT test cases were migrated with the script provided by Nikita Popov. Due to the size of the change it is split into several parts. Reviewed By: nemanja, nikic Differential Revision: https://reviews.llvm.org/D135474
This patch fixes the following two bugs in `PPCInstrInfo::isSignOrZeroExtended` helper, which is used from sign-/zero-extension elimination in PPCMIPeephole pass. - Registers defined by load with update (e.g. LBZU) were identified as already sign or zero-extended. But it is true only for the first def (loaded value) and not for the second def (i.e. updated pointer). - Registers defined by ORIS/XORIS were identified as already sign-extended. But, it is not true for sign extension depending on the immediate (while it is ok for zero extension). To handle the first case, the parameter for the helpers is changed from `MachineInstr` to a register number to distinguish first and second defs. Also, this patch moves the initialization of PPCMIPeepholePass to allow mir test case. Reviewed By: nemanjai Differential Revision: https://reviews.llvm.org/D40554
Summary: This patch add the InstAlias definitions for below instructions. ADDI ADDIS ADDI8 ADDIS8 RLWINM8 ISEL ISEL8 OR OR_rec ORI ORI8 XORI8 CNTLZW8 CNTLZW8_rec TEND TSR RFEBB NOR NOR_rec MTCRF SUBF SUBF_rec SUBFC SUBFC_rec RLDICL_32_64 TW Reviewed By: steven.zhang Differential Revision: https://reviews.llvm.org/D77559
Summary: When doing the conversion: MachineInst -> MCInst, we should ignore the implicit operands, it will expose more opportunity for InstiAlias. Reviewed By: steven.zhang Differential Revision: https://reviews.llvm.org/D77118
This re-commits everything that was pulled in r314244. The transformation is off by default (patch to enable it to follow). The code is refactored to have a single entry-point and provide fine-grained control over patterns that it selects. This patch also fixes the bugs in the original code. Everything that failed with the original patch has been re-tested with this patch (with the transformation turned on). So the patch to turn this on is soon to follow. Differential Revision: https://reviews.llvm.org/D38575 llvm-svn: 319434
In the past while, I've committed a number of patches in the PowerPC back end aimed at eliminating comparison instructions. However, this causes some failures in proprietary source and these issues are not observed in SPEC or any open source packages I've been able to run. As a result, I'm pulling the entire series and will refactor it to: - Have a single entry point for easy control - Have fine-grained control over which patterns we transform A side-effect of this is that test cases for these patches (and modified by them) are XFAIL-ed. This is a temporary measure as it is counter-productive to remove/modify these test cases and then have to modify them again when the refactored patch is recommitted. The failure will be investigated in parallel to the refactoring effort and the recommit will either have a fix for it or will leave this transformation off by default until the problem is resolved. llvm-svn: 314244
As mentioned in https://reviews.llvm.org/D33718, this simply adds another pattern to the compare elimination sequence and is committed without a differential review. llvm-svn: 314106
Generally, the ISEL is expanded into if-then-else sequence, in some cases (like when the destination register is the same with the true or false value register), it may just be expanded into just the if or else sequence. llvm-svn: 292154