aboutsummaryrefslogtreecommitdiffstats
path: root/test/CodeGen/PowerPC/asym-regclass-copy.ll
Commit message (Collapse)AuthorAgeFilesLines
* Update to remove the no-frame-pointer-elim-non-leaf flag if it was set to ↵Bill Wendling2013-08-221-1/+1
| | | | | | 'false'. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189068 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix a register-class comparison bug in PPCCTRLoopsHal Finkel2013-03-211-1/+2
| | | | | | | | | Thanks to Jakob for isolating the underlying problem from the test case in r177423. The original commit had introduced asymmetric copy operations, but these turned out to be a work-around to the real problem (the use of == instead of hasSubClassEq in PPCCTRLoops). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177679 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a comment to the CodeGen/PowerPC/asym-regclass-copy.ll testHal Finkel2013-03-191-0/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177434 91177308-0d34-0410-b5e6-96231b3b80d8
* Prepare to make r0 an allocatable register on PPCHal Finkel2013-03-191-0/+53
Currently the PPC r0 register is unconditionally reserved. There are two reasons for this: 1. r0 is treated specially (as the constant 0) by certain instructions, and so cannot be used with those instructions as a regular register. 2. r0 is used as a temporary register in the CR-register spilling process (where, under some circumstances, we require two GPRs). This change addresses the first reason by introducing a restricted register class (without r0) for use by those instructions that treat r0 specially. These register classes have a new pseudo-register, ZERO, which represents the r0-as-0 use. This has the side benefit of making the existing target code simpler (and easier to understand), and will make it clear to the register allocator that uses of r0 as 0 don't conflict will real uses of the r0 register. Once the CR spilling code is improved, we'll be able to allocate r0. Adding these extra register classes, for some reason unclear to me, causes requests to the target to copy 32-bit registers to 64-bit registers. The resulting code seems correct (and causes no test-suite failures), and the new test case covers this new kind of asymmetric copy. As r0 is still reserved, no functionality change intended. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177423 91177308-0d34-0410-b5e6-96231b3b80d8