http://llvm.org https://git.amat.us/llvm/atom/test/CodeGen/PowerPC?h=release_33 2013-05-09T07:33:50Z 2013-05-09T07:33:50Z Bill Wendling isanbard@gmail.com 2013-05-09T07:33:50Z urn:sha1:5f32469bd4d236a84313580c97085abb385ed605 ------------------------------------------------------------------------ r181423 | hfinkel | 2013-05-08 05:16:14 -0700 (Wed, 08 May 2013) | 5 lines PPCInstrInfo::optimizeCompareInstr should not optimize FP compares The floating-point record forms on PPC don't set the condition register bits based on a comparison with zero (like the integer record forms do), but rather based on the exception status bits. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_33@181507 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-30T20:04:37Z Hal Finkel hfinkel@anl.gov 2013-04-30T20:04:37Z urn:sha1:db31bd31d62b5b85dddd5fbecae1a04a02201adc First, taking advantage of the fact that the virtual base registers are allocated in order of the local frame offsets, remove the quadratic register-searching behavior. Because of the ordering, we only need to check the last virtual base register created. Second, store the frame index in the FrameRef structure, and get the frame index and the local offset from this structure at the top of the loop iteration. This allows us to de-nest the loops in insertFrameReferenceRegisters (and I think makes the code cleaner). I also moved the needsFrameBaseReg check into the first loop over instructions so that we don't bother pushing FrameRefs for instructions that don't want a virtual base register anyway. Lastly, and this is the only functionality change, avoid the creation of single-use virtual base registers. These are currently not useful because, in general, they end up replacing what would be one r+r instruction with an add and a r+i instruction. Committing this removes the XFAIL in CodeGen/PowerPC/2007-09-07-LoadStoreIdxForms.ll Jim has okayed this off-list. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180799 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-30T17:52:57Z Manman Ren mren@apple.com 2013-04-30T17:52:57Z urn:sha1:2dc50d306752c8672d1543feb88517705cdb25e7 This will make it easier to turn on struct-path aware TBAA since the metadata format will change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180796 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-27T00:43:16Z Rafael Espindola rafael.espindola@gmail.com 2013-04-27T00:43:16Z urn:sha1:5b0ce3570c03919f71cab6ef8ed2312d2b707ca2 This fixes pr15763. Patch by David Fang. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180657 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-19T22:08:38Z Hal Finkel hfinkel@anl.gov 2013-04-19T22:08:38Z urn:sha1:87c1e42be7dadaea7c3e00fb7ccbd77633cea37f When matching a compare with a subtract where the arguments of the compare are swapped w.r.t. the arguments of the subtract, we need to negate the predicates (or CR bit indices) of the users. This, however, is not the same as inverting the predicate (negating LT -> GT, but inverting LT -> GE, for example). The ARM backend seems to do this correctly, but when I adapted the code for the PPC backend, I introduced an error in this logic. Comparison optimization is now enabled again by default. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179899 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-18T22:54:25Z Hal Finkel hfinkel@anl.gov 2013-04-18T22:54:25Z urn:sha1:4029c3feed5c9a5b0793e3da140ecaabef19e3fe This seems to cause a stage-2 LLVM compile failure (by crashing TableGen); do I'm disabling this for now. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179807 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-18T22:15:08Z Hal Finkel hfinkel@anl.gov 2013-04-18T22:15:08Z urn:sha1:860c08cad5b7c1359123bb2b0e74df4b6e48a15c Many PPC instructions have a so-called 'record form' which stores to a specific condition register the result of comparing the result of the instruction with zero (always as a signed comparison). For integer operations on PPC64, this is always a 64-bit comparison. This implementation is derived from the implementation in the ARM backend; there are some differences because PPC condition registers are allocatable virtual registers (although the record forms always use a specific one), and we look for a matching subtraction instruction after the compare (but before the first use) in addition to before it. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179802 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-15T02:07:05Z Hal Finkel hfinkel@anl.gov 2013-04-15T02:07:05Z urn:sha1:fb6fe0aea2d1adde6d5e86f43797b5795ff2dc36 This fixes an ABI bug for non-Darwin PPC64. For the callee-saved condition registers, the spill location is specified relative to the stack pointer (SP + 8). However, this is not relative to the SP after the new stack frame is established, but instead relative to the caller's stack pointer (it is stored into the linkage area of the parent's stack frame). So, like with the link register, we don't directly spill the CRs with other callee-saved registers, but just mark them to be spilled during prologue generation. In practice, this reverts r179457 for PPC64 (but leaves it in place for PPC32). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179500 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-13T08:09:20Z Hal Finkel hfinkel@anl.gov 2013-04-13T08:09:20Z urn:sha1:b99c995825a49f0da5af40ee1b61269deb8994b5 For functions that need to spill CRs, and have dynamic stack allocations, the value of the SP during the restore is not what it was during the save, and so we need to use the FP in these cases (as for all of the other spills and restores, but the CR restore has a special code path because its reserved slot, like the link register, is specified directly relative to the adjusted SP). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179457 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-12T04:06:46Z Nico Rieck nico.rieck@gmail.com 2013-04-12T04:06:46Z urn:sha1:f89da7210b09a0a0f7c9ee216cd54dca03c6b64a git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179361 91177308-0d34-0410-b5e6-96231b3b80d8