http://llvm.org https://git.amat.us/llvm/atom/lib/Target/PowerPC?h=release_32 2012-11-29T00:42:22Z 2012-11-29T00:42:22Z Hal Finkel hfinkel@anl.gov 2012-11-29T00:42:22Z urn:sha1:0bf24700008587be800865149b7e58b374de6fbf git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_32@168842 91177308-0d34-0410-b5e6-96231b3b80d8 2012-11-20T03:57:32Z Hal Finkel hfinkel@anl.gov 2012-11-20T03:57:32Z urn:sha1:3c221ac6795fd523c7b30846a26de1479ee14c73 git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_32@168351 91177308-0d34-0410-b5e6-96231b3b80d8 2012-11-20T03:47:28Z Hal Finkel hfinkel@anl.gov 2012-11-20T03:47:28Z urn:sha1:c21252912a845335b30f64f72a149e034f173ffd git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_32@168350 91177308-0d34-0410-b5e6-96231b3b80d8 2012-11-05T19:39:45Z Ulrich Weigand ulrich.weigand@de.ibm.com 2012-11-05T19:39:45Z urn:sha1:86aef0a4f093700420c76f313e5668c39db110aa to be extended to a full register. This is modeled in the IR by marking the return value (or argument) with a signext or zeroext attribute. However, while these attributes are respected for function arguments, they are currently ignored for function return values by the PowerPC back-end. This patch updates PPCCallingConv.td to ask for the promotion to i64, and fixes LowerReturn and LowerCallResult to implement it. The new test case verifies that both arguments and return values are properly extended when passing them; and also that the optimizers understand incoming argument and return values are in fact guaranteed by the ABI to be extended. The patch caused a spurious breakage in CodeGen/PowerPC/coalesce-ext.ll, since the test case used a "ret" instruction to create a use of an i32 value at the end of the function (to set up data flow as required for what the test is intended to test). Since there's now an implicit promotion to i64, that data flow no longer works as expected. To fix this, this patch now adds an extra "add" to ensure we have an appropriate use of the i32 value. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167396 91177308-0d34-0410-b5e6-96231b3b80d8 2012-11-05T18:18:42Z Hal Finkel hfinkel@anl.gov 2012-11-05T18:18:42Z urn:sha1:827b7a070d349737f1d6ff63115e0cbb0c031f9c The Z constraint specifies an r+r memory address, and the y modifier expands to the "r, r" in the asm string. For this initial implementation, the base register is forced to r0 (which has the special meaning of 0 for r+r addressing on PowerPC) and the full address is taken in the second register. In the future, this should be improved. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167388 91177308-0d34-0410-b5e6-96231b3b80d8 2012-11-05T17:15:56Z Adhemerval Zanella azanella@linux.vnet.ibm.com 2012-11-05T17:15:56Z urn:sha1:cfe09ed28d8a65b671e8b7a716a933e98e810e32 This patch expands the SEXTLOAD, ZEXTLOAD, and EXTLOAD operations for vector types when altivec is enabled. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167386 91177308-0d34-0410-b5e6-96231b3b80d8 2012-11-01T09:14:31Z Chandler Carruth chandlerc@gmail.com 2012-11-01T09:14:31Z urn:sha1:426c2bf5cdd2173e4a33aea8cb92cf684a724f4b r165941: Resubmit the changes to llvm core to update the functions to support different pointer sizes on a per address space basis. Despite this commit log, this change primarily changed stuff outside of VMCore, and those changes do not carry any tests for correctness (or even plausibility), and we have consistently found questionable or flat out incorrect cases in these changes. Most of them are probably correct, but we need to devise a system that makes it more clear when we have handled the address space concerns correctly, and ideally each pass that gets updated would receive an accompanying test case that exercises that pass specificaly w.r.t. alternate address spaces. However, from this commit, I have retained the new C API entry points. Those were an orthogonal change that probably should have been split apart, but they seem entirely good. In several places the changes were very obvious cleanups with no actual multiple address space code added; these I have not reverted when I spotted them. In a few other places there were merge conflicts due to a cleaner solution being implemented later, often not using address spaces at all. In those cases, I've preserved the new code which isn't address space dependent. This is part of my ongoing effort to clean out the partial address space code which carries high risk and low test coverage, and not likely to be finished before the 3.2 release looms closer. Duncan and I would both like to see the above issues addressed before we return to these changes. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167222 91177308-0d34-0410-b5e6-96231b3b80d8 2012-11-01T08:07:29Z Chandler Carruth chandlerc@gmail.com 2012-11-01T08:07:29Z urn:sha1:ece6c6bb6329748b92403c06ac87f45c43485911 getIntPtrType support for multiple address spaces via a pointer type, and also introduced a crasher bug in the constant folder reported in PR14233. These commits also contained several problems that should really be addressed before they are re-committed. I have avoided reverting various cleanups to the DataLayout APIs that are reasonable to have moving forward in order to reduce the amount of churn, and minimize the number of commits that were reverted. I've also manually updated merge conflicts and manually arranged for the getIntPtrType function to stay in DataLayout and to be defined in a plausible way after this revert. Thanks to Duncan for working through this exact strategy with me, and Nick Lewycky for tracking down the really annoying crasher this triggered. (Test case to follow in its own commit.) After discussing with Duncan extensively, and based on a note from Micah, I'm going to continue to back out some more of the more problematic patches in this series in order to ensure we go into the LLVM 3.2 branch with a reasonable story here. I'll send a note to llvmdev explaining what's going on and why. Summary of reverted revisions: r166634: Fix a compiler warning with an unused variable. r166607: Add some cleanup to the DataLayout changes requested by Chandler. r166596: Revert "Back out r166591, not sure why this made it through since I cancelled the command. Bleh, sorry about this! r166591: Delete a directory that wasn't supposed to be checked in yet. r166578: Add in support for getIntPtrType to get the pointer type based on the address space. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167221 91177308-0d34-0410-b5e6-96231b3b80d8 2012-10-31T01:15:05Z Bill Schmidt wschmidt@linux.vnet.ibm.com 2012-10-31T01:15:05Z urn:sha1:42d43351b274603ed0ac28128498a35b8987ce15 parameters. Examples of these are: struct { } a; union { } b[256]; int a[0]; An empty aggregate has an address, although dereferencing that address is pointless. When passed as a parameter, an empty aggregate does not consume a protocol register, nor does it consume a doubleword in the parameter save area. Passing an empty aggregate by reference passes an address just as for any other aggregate. Returning an empty aggregate uses GPR3 as a hidden address of the return value location, just as for any other aggregate. The patch modifies PPCTargetLowering::LowerFormalArguments_64SVR4 and PPCTargetLowering::LowerCall_64SVR4 to properly skip empty aggregate parameters passed by value. The handling of return values and by-reference parameters was already correct. Built on powerpc64-unknown-linux-gnu and tested with no new regressions. A test case is included to test proper handling of empty aggregate parameters on both sides of the function call protocol. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167090 91177308-0d34-0410-b5e6-96231b3b80d8 2012-10-30T18:29:42Z Adhemerval Zanella azanella@linux.vnet.ibm.com 2012-10-30T18:29:42Z urn:sha1:c83b5dc625bd85276a23c36c1fbad193203d2bc7 This patch expands FSQRT for floating point vector types when altivec is used. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167034 91177308-0d34-0410-b5e6-96231b3b80d8