http://llvm.org https://git.amat.us/llvm/atom/test/CodeGen/PowerPC?h=master 2013-05-13T19:34:37Z 2013-05-13T19:34:37Z Bill Schmidt wschmidt@linux.vnet.ibm.com 2013-05-13T19:34:37Z urn:sha1:240b9b6078cdf8048945107b4ff7d517729dab96 This fixes warning messages observed in the oggenc application test in projects/test-suite. Special handling is needed for the 64-bit PowerPC SVR4 ABI when a constant is initialized with a pointer to a function in a shared library. Because a function address is implemented as the address of a function descriptor, the use of copy relocations can lead to problems with initialization. GNU ld therefore replaces copy relocations with dynamic relocations to be resolved by the dynamic linker. This means the constant cannot reside in the read-only data section, but instead belongs in .data.rel.ro, which is designed for constants containing dynamic relocations. The implementation creates a class PPC64LinuxTargetObjectFile inheriting from TargetLoweringObjectFileELF, which behaves like its parent except to place constants of this sort into .data.rel.ro. The test case is reduced from the oggenc application. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181723 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-08T17:22:33Z Bill Schmidt wschmidt@linux.vnet.ibm.com 2013-05-08T17:22:33Z urn:sha1:a7f2ce85e5bd8d2826537f50ac510ef9fbe83792 This fixes bug 15821 similarly to the powerpc64-linux fix for bug 14779. Patch by David Fang. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181449 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-08T12:16:14Z Hal Finkel hfinkel@anl.gov 2013-05-08T12:16:14Z urn:sha1:b45eb9fd275f857788cabb15ef8aabf0ff5907cc 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/trunk@181423 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