aboutsummaryrefslogtreecommitdiffstats
path: root/lib/Target/PowerPC
Commit message (Collapse)AuthorAgeFilesLines
...
* [PowerPC] Add integer truncation support to fast-isel.Bill Schmidt2013-08-301-0/+31
| | | | | | | | | | | | | This is the last substantive patch I'm planning for fast-isel in the near future, adding fast selection of integer truncates. There are certainly more things that can be improved (many of which are called out in FIXMEs), but for now we are catching most of the important cases. I'll document some of the remaining work in a cleanup patch shortly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189706 91177308-0d34-0410-b5e6-96231b3b80d8
* Correct partially defined variableBill Schmidt2013-08-301-1/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189705 91177308-0d34-0410-b5e6-96231b3b80d8
* [PowerPC] Call support for fast-isel.Bill Schmidt2013-08-303-3/+338
| | | | | | | | | | This patch adds fast-isel support for calls (but not intrinsic calls or varargs calls). It also removes a badly-formed assert. There are some new tests just for calls, and also for folding loads into arguments on calls to avoid extra extends. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189701 91177308-0d34-0410-b5e6-96231b3b80d8
* [PowerPC] Add handling for conversions to fast-isel.Bill Schmidt2013-08-304-0/+288
| | | | | | | | | | Yet another chunk of fast-isel code. This one handles various conversions involving floating-point. (It also includes some miscellaneous handling throughout the back end for LWA_32 and LWAX_32 that should have been part of the load-store patch.) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189677 91177308-0d34-0410-b5e6-96231b3b80d8
* [PowerPC] Handle selection of compare instructions in fast-isel.Bill Schmidt2013-08-301-0/+18
| | | | | | | | Mostly trivial patch adding support for compares. The meat of the work was added with the branch support. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189639 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove bogus debug statement. Sheesh.Bill Schmidt2013-08-301-4/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189638 91177308-0d34-0410-b5e6-96231b3b80d8
* [PowerPC] Add loads, stores, and related things to fast-isel.Bill Schmidt2013-08-303-7/+776
| | | | | | | | | | | | | | | | | | | | | | | | | | | This is the next big chunk of fast-isel code. The primary purpose is to implement selection of loads and stores, but there is a lot of drag-along to support this. The common code to analyze addresses for both loads and stores is substantial. It's also necessary to add the materialization code for global values. Related to load-store processing is the code to fold loads into integer extends, since otherwise we generate lots of redundant instructions. We also need to add some overrides to some FastEmit routines to ensure we don't assign GPR 0 to a virtual register when this would change the meaning of an instruction. I added handling selection of a few binary arithmetic instructions, to enable committing some test cases I wrote a while back. Finally, ap couple of miscellaneous changes: * I cleaned up some poor style from a previous patch in PPCISelLowering.cpp, pointed out by David Blaikie. * I enlarged the Addr.Offset field to avoid sign problems with 32-bit offsets. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189636 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix use of uninitialized value added in r189400 (found by MemorySanitizer)Alexey Samsonov2013-08-281-4/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189456 91177308-0d34-0410-b5e6-96231b3b80d8
* Given target assembler parsers a chance to handle variant expressionsJoerg Sonnenberger2013-08-272-3/+31
| | | | | | | | first. Use this to turn the PPC modifiers into PPC specific expressions, allowing them to work on constants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189400 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Fix the build broken by r189315." and "Move everything depending on ↵Charles Davis2013-08-272-50/+46
| | | | | | | | | Object/MachOFormat.h over to Support/MachO.h." This reverts commits r189319 and r189315. r189315 broke some tests on what I believe are big-endian platforms. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189321 91177308-0d34-0410-b5e6-96231b3b80d8
* Move everything depending on Object/MachOFormat.h over to Support/MachO.h.Charles Davis2013-08-272-46/+50
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189315 91177308-0d34-0410-b5e6-96231b3b80d8
* Dummy code to silence warning from 4189266Bill Schmidt2013-08-262-0/+11
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189272 91177308-0d34-0410-b5e6-96231b3b80d8
* [PowerPC] More fast-isel chunks (returns and integer extends)Bill Schmidt2013-08-263-3/+255
| | | | | | | | | | | | | | | | | | Incremental improvement to fast-isel for PPC64. This allows us to select on ret, sext, and zext. Filling in sext/zext improves some of the existing logic in handling compare-immediates that needed extends. A simplified return convention for fast-isel is also added to the PPC64 calling conventions. All call/return processing for DAG selection is handled with custom code, so there isn't an existing CC to rely on here. The include of PPCGenCallingConv.inc causes compiler warnings due to the 32-bit calling conventions that are not used, so the dummy function "usePPC32CCs()" is added here to silence those. Test cases for the return and extend logic are added. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189266 91177308-0d34-0410-b5e6-96231b3b80d8
* [PowerPC] Add fast-isel branch and compare selection.Bill Schmidt2013-08-251-9/+272
| | | | | | | | | | | | | First chunk of actual fast-isel selection code. This handles direct and indirect branches, as well as feeding compares for direct branches. PPCFastISel::PPCEmitIntExt() is just roughed in and will be expanded in a future patch. This also corrects a problem with selection for constant pool entries in JIT mode or with small code model. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189202 91177308-0d34-0410-b5e6-96231b3b80d8
* [PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.Bill Schmidt2013-08-201-271/+194
| | | | | | | | | | | | | | | | | | | | | | | | | | | | (Patch committed on behalf of Mark Minich, whose log entry follows.) This is a continuation of the refactorings performed in svn rev 188573 (see that rev's comments for more detail). This is my stage 2 refactoring: I combined the emitPrologue() & emitEpilogue() PPC32 & PPC64 code into a single flow, simplifying a lot of the code since in essence the PPC32 & PPC64 code generation logic is the same, only the instruction forms are different (in most cases). This simplification is necessary because my functional changes (yet to come) add significant complexity, and without the simplification of my stage 2 refactoring, the overall complexity of both emitPrologue() & emitEpilogue() would have become almost intractable for most mortal programmers (like me). This submission was intended to be a pure refactoring (no functional changes whatsoever). However, in the process of combining the PPC32 & PPC64 flows, I spotted a difference that I believe is a bug (see svn rev 186478 line 863, or svn rev 188573 line 888): This line appears to be restoring the BP with the original FP content, not the original BP content. When I merged the 32-bit and 64-bit code, I used the corresponding code from the 64-bit flow, which I believe uses the correct offset (BPOffset) for this operation. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188741 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a llvm.copysign intrinsicHal Finkel2013-08-191-0/+6
| | | | | | | | | | | | | | | | | | | | | This adds a llvm.copysign intrinsic; We already have Libfunc recognition for copysign (which is turned into the FCOPYSIGN SDAG node). In order to autovectorize calls to copysign in the loop vectorizer, we need a corresponding intrinsic as well. In addition to the expected changes to the language reference, the loop vectorizer, BasicTTI, and the SDAG builder (the intrinsic is transformed into an FCOPYSIGN node, just like the function call), this also adds FCOPYSIGN to a few lists in LegalizeVector{Ops,Types} so that vector copysigns can be expanded. In TargetLoweringBase::initActions, I've made the default action for FCOPYSIGN be Expand for vector types. This seems correct for all in-tree targets, and I think is the right thing to do because, previously, there was no way to generate vector-values FCOPYSIGN nodes (and most targets don't specify an action for vector-typed FCOPYSIGN). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188728 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't form PPC CTR-based loops around a copysignl callHal Finkel2013-08-191-1/+2
| | | | | | | | | copysign/copysignf never become function calls (because the SDAG expansion code does not lower to the corresponding function call, but rather directly implements the associated logic), but copysignl almost always is lowered into a call to the requested libm functon (and, thus, might clobber CTR). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188727 91177308-0d34-0410-b5e6-96231b3b80d8
* Add the PPC fcpsgn instructionHal Finkel2013-08-195-7/+45
| | | | | | | | | Modern PPC cores support a floating-point copysign instruction, and we can use this to lower the FCOPYSIGN node (which is created from calls to the libm copysign function). A couple of extra patterns are necessary because the operand types of FCOPYSIGN need not agree. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188653 91177308-0d34-0410-b5e6-96231b3b80d8
* [PowerPC] Preparatory refactoring for making prologue and epilogueBill Schmidt2013-08-161-85/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | safe on PPC32 SVR4 ABI [Patch and following text by Mark Minich; committing on his behalf.] There are FIXME's in PowerPC/PPCFrameLowering.cpp, method PPCFrameLowering::emitPrologue() related to "negative offsets of R1" on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4 (and any ABI without a Red Zone), no spills may be made until after the stackframe is claimed, which also includes the LR spill which is at a positive offset. The same problem exists in emitEpilogue(), though there's no FIXME for it. I intend to fix this issue, making LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit platforms (including in particular, OS-free embedded systems & kernel code, where interrupts may share the same stack as user code). In preparation for making these changes, to make the diffs for the functional changes less cluttered, I am providing the non-functional refactorings in two stages: Stage 1 does some minor fluffy refactorings to pull multiple method calls up into a single bool, creating named bools for repeated uses of obscure logic, moving some code up earlier because either stage 2 or my final version will require it earlier, and rewording/adding some comments. My stage 1 changes can be characterized as primarily fluffy cleanup, the purpose of which may be unclear until the stage 2 or final changes are made. My stage 2 refactorings combine the separate PPC32 & PPC64 logic, which is currently performed by largely duplicate code, into a single flow, with the differences handled by a group of constants initialized early in the methods. This submission is for my stage 1 changes. There should be no functional changes whatsoever; this is a pure refactoring. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188573 91177308-0d34-0410-b5e6-96231b3b80d8
* Replace getValueType().getSimpleVT() with getSimpleValueType(). Also remove ↵Craig Topper2013-08-151-4/+4
| | | | | | one weird cast from MVT->EVT just to call getSimpleVT(). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188441 91177308-0d34-0410-b5e6-96231b3b80d8
* Actually fix PPC64 64-bit GPR inline asm constraint matchingHal Finkel2013-08-141-1/+1
| | | | | | | | | | This is a follow-up to r187693, correcting that code to request the correct register class. The previous version, with the wrong register class, was not really correcting the constraints, but rather was removing them. Coincidentally, this fixed the failing test case in r187693, but obviously created other problems. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188407 91177308-0d34-0410-b5e6-96231b3b80d8
* cast fix to appease buildbotDavid Fang2013-08-081-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188014 91177308-0d34-0410-b5e6-96231b3b80d8
* initial draft of PPCMachObjectWriter.cppDavid Fang2013-08-084-19/+395
| | | | | | | | this records relocation entries in the mach-o object file for PIC code generation. tested on powerpc-darwin8, validated against darwin otool -rvV git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188004 91177308-0d34-0410-b5e6-96231b3b80d8
* PPC: Map frin to round() not nearbyint() and rint()Hal Finkel2013-08-082-68/+4
| | | | | | | | | | | | | | | Making use of the recently-added ISD::FROUND, which allows for custom lowering of round(), the PPC backend will now map frin to round(). Previously, we had been using frin to lower nearbyint() (and rint() via some custom lowering to handle the extra fenv flags requirements), but only in fast-math mode because frin does not tie-to-even. Several users had complained about this behavior, and this new mapping of frin to round is certainly more appropriate (and does not require fast-math mode). In effect, this reverts r178362 (and part of r178337, replacing the nearbyint mapping with the round mapping). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187960 91177308-0d34-0410-b5e6-96231b3b80d8
* Add ISD::FROUND for libm round()Hal Finkel2013-08-071-0/+5
| | | | | | | | | | | | | | | All libm floating-point rounding functions, except for round(), had their own ISD nodes. Recent PowerPC cores have an instruction for round(), and so here I'm adding ISD::FROUND so that round() can be custom lowered as well. For the most part, this is straightforward. I've added an intrinsic and a matching ISD node just like those for nearbyint() and friends. The SelectionDAG pattern I've named frnd (because ISD::FP_ROUND has already claimed fround). This will be used by the PowerPC backend in a follow-up commit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187926 91177308-0d34-0410-b5e6-96231b3b80d8
* Add PPC64 mulli patternHal Finkel2013-08-061-0/+3
| | | | | | | | The PPC backend had been missing a pattern to generate mulli for 64-bit multiples. We had been generating it only for 32-bit multiplies. Unfortunately, generating li + mulld unnecessarily increases register pressure. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187807 91177308-0d34-0410-b5e6-96231b3b80d8
* Target/*/CMakeLists.txt: Add the dependency to CommonTableGen explicitly for ↵NAKAMURA Takumi2013-08-061-1/+1
| | | | | | | | | each corresponding CodeGen. Without explicit dependencies, both per-file action and in-CommonTableGen action could run in parallel. It races to emit *.inc files simultaneously. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187780 91177308-0d34-0410-b5e6-96231b3b80d8
* PPCAsmParser: Stop leaking names.Benjamin Kramer2013-08-031-10/+31
| | | | | | Store them in a place that gets cleaned up properly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187700 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix PPC64 64-bit GPR inline asm constraint matchingHal Finkel2013-08-031-1/+18
| | | | | | | | | | | | | | | Internally, the PowerPC backend names the 32-bit GPRs R[0-9]+, and names the 64-bit parent GPRs X[0-9]+. When matching inline assembly constraints with explicit register names, on PPC64 when an i64 MVT has been requested, we need to follow gcc's convention of using r[0-9]+ to refer to the 64-bit (parent) registers. At some point, we'll probably want to arrange things so that the generic code in TargetLowering uses the AsmName fields declared in *RegisterInfo.td in order to match these inline asm register constraints. If we do that, this change can be reverted. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187693 91177308-0d34-0410-b5e6-96231b3b80d8
* Use function attributes to indicate that we don't want to realign the stack.Bill Wendling2013-08-011-1/+1
| | | | | | | | | Function attributes are the future! So just query whether we want to realign the stack directly from the function instead of through a random target options structure. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187618 91177308-0d34-0410-b5e6-96231b3b80d8
* [PowerPC] Skeletal FastISel support for 64-bit PowerPC ELF.Bill Schmidt2013-07-305-1/+347
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the first of many upcoming patches for PowerPC fast instruction selection support. This patch implements the minimum necessary for a functional (but extremely limited) FastISel pass. It allows the table-generated portions of the selector to be created and used, but in most cases selection will fall back to the DAG selector. None of the block terminator instructions are implemented yet, and most interesting instructions require some special handling. Therefore there aren't any new test cases with this patch. There will be quite a few tests coming with future patches. This patch adds the make/CMake support for the new code (including tablegen -gen-fast-isel) and creates the FastISel object for PPC64 ELF only. It instantiates the necessary virtual functions (TargetSelectInstruction, TargetMaterializeConstant, TargetMaterializeAlloca, tryToFoldLoadIntoMI, and FastLowerArguments), but of these, only TargetMaterializeConstant contains any useful implementation. This is present since the table-generated code requires the ability to materialize integer constants for some instructions. This patch has been tested by building and running the projects/test-suite code with -O0. All tests passed with the exception of a couple of long-running tests that time out using -O0 code generation. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187399 91177308-0d34-0410-b5e6-96231b3b80d8
* [PowerPC] Add comment explaining preprocessor directive.Bill Schmidt2013-07-281-0/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187320 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert 187318Bill Schmidt2013-07-281-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187319 91177308-0d34-0410-b5e6-96231b3b80d8
* [PowerPC] Remove unnecessary preprocessor checking.Bill Schmidt2013-07-281-1/+1
| | | | | | | | | | The tests !defined(__ppc__) && !defined(__powerpc__) are not needed or helpful when verifying that code is being compiled for a 64-bit target. The simpler test provided by this revision is sufficient to tell if the target is 64-bit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187318 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[PowerPC] Improve consistency in use of __ppc__, __powerpc__, etc."Rafael Espindola2013-07-261-3/+3
| | | | | | This reverts commit r187248. It broke many bots. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187254 91177308-0d34-0410-b5e6-96231b3b80d8
* [PowerPC] Improve consistency in use of __ppc__, __powerpc__, etc.Bill Schmidt2013-07-261-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Both GCC and LLVM will implicitly define __ppc__ and __powerpc__ for all PowerPC targets, whether 32- or 64-bit. They will both implicitly define __ppc64__ and __powerpc64__ for 64-bit PowerPC targets, and not for 32-bit targets. We cannot be sure that all other possible compilers used to compile Clang/LLVM define both __ppc__ and __powerpc__, for example, so it is best to check for both when relying on either inside the Clang/LLVM code base. This patch makes sure we always check for both variants. In addition, it fixes one unnecessary check in lib/Target/PowerPC/PPCJITInfo.cpp. (At least one of __ppc__ and __powerpc__ should always be defined when compiling for a PowerPC target, no matter which compiler is used, so testing for them is unnecessary.) There are some places in the compiler that check for other variants, like __POWERPC__ and _POWER, and I have left those in place. There is no need to add them elsewhere. This seems to be in Apple-specific code, and I won't take a chance on breaking it. There is no intended change in behavior; thus, no test cases are added. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187248 91177308-0d34-0410-b5e6-96231b3b80d8
* [PowerPC] Support powerpc64le as a syntax-checking target.Bill Schmidt2013-07-2610-7/+44
| | | | | | | | | | | | | | | | | | | | | | | | This patch provides basic support for powerpc64le as an LLVM target. However, use of this target will not actually generate little-endian code. Instead, use of the target will cause the correct little-endian built-in defines to be generated, so that code that tests for __LITTLE_ENDIAN__, for example, will be correctly parsed for syntax-only testing. Code generation will otherwise be the same as powerpc64 (big-endian), for now. The patch leaves open the possibility of creating a little-endian PowerPC64 back end, but there is no immediate intent to create such a thing. The LLVM portions of this patch simply add ppc64le coverage everywhere that ppc64 coverage currently exists. There is nothing of any import worth testing until such time as little-endian code generation is implemented. In the corresponding Clang patch, there is a new test case variant to ensure that correct built-in defines for little-endian code are generated. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187179 91177308-0d34-0410-b5e6-96231b3b80d8
* PPC32 va_list is an actual structure so va_copy needs to copy the wholeRoman Divacky2013-07-252-1/+23
| | | | | | | | structure not just a pointer. This implements that and thus fixes va_copy on PPC32. Fixes #15286. Both bug and patch by Florian Zeitz! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187158 91177308-0d34-0410-b5e6-96231b3b80d8
* allow tests to run on powerpc-darwin8 again, checking for __ppc__David Fang2013-07-241-2/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187027 91177308-0d34-0410-b5e6-96231b3b80d8
* Split generated asm mnemonic matching table into a separate table for each ↵Craig Topper2013-07-241-0/+1
| | | | | | | | | | asm variant. This removes the need to store the asm variant in each row of the single table that existed before. Shaves ~16K off the size of X86AsmParser.o. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187026 91177308-0d34-0410-b5e6-96231b3b80d8
* PPC: Support dynamic allocas with large alignmentHal Finkel2013-07-182-27/+53
| | | | | | | | | | | | | | | Support for dynamic stack alignments in the PPC backend has been unfinished, in part because it depends on dynamic stack realignment (which I only just recently implemented fully). Now we can also support dynamic allocas with higher than the default target stack alignment (16 bytes). In order to round-up the requested size to the maximum requested alignment, we need an additional register to hold the rounded-up size. We're already using one scavenged register to hold the previous stack-pointer value (which needs to be stored with the signal-safe stdux update), and so when we have dynamic allocas and a large alignment, we allocate two emergency spill slots for the scavenger. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186562 91177308-0d34-0410-b5e6-96231b3b80d8
* PPC: Add base-pointer support to builtin setjmp/longjmpHal Finkel2013-07-175-41/+72
| | | | | | | | | | | | | | | | | | First, this changes the base-pointer implementation to remove an unnecessary complication (and one that is incompatible with how builtin SjLj is implemented): instead of using r31 as the base pointer when it is not needed as a frame pointer, now the base pointer will always be r30 when needed. Second, we introduce another pseudo register, BP, which is used just like the FP pseudo register to refer to the base register before we know for certain what register it will be. Third, we now save BP into the jmp_buf, and restore r30 from that slot in longjmp. If the function that called setjmp did not use a base pointer, then r30 will be overwritten by the setjmp-calling-function's restore code. FP restoration (which is restored into r31) works the same way. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186545 91177308-0d34-0410-b5e6-96231b3b80d8
* PPC: Add CTR-register clobber to builtin setjmpHal Finkel2013-07-173-0/+9
| | | | | | | | | | | | | Because the builtin longjmp implementation uses a CTR-based indirect jump, when the control flow arrives at the builtin setjmp call, the CTR register has necessarily been clobbered. Correspondingly, this adds CTR to the list of implicit definitions of the builtin setjmp pseudo instruction. We don't need to add CTR to the implicit definitions of builtin longjmp because, even though it does clobber the CTR register, the control flow cannot return to inside the loop unless there is also a builtin setjmp call. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186488 91177308-0d34-0410-b5e6-96231b3b80d8
* PPC: Implement base pointer and stack realignmentHal Finkel2013-07-175-41/+240
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This builds on some frame-lowering code that has existed since 2005 (r24224) but was disabled in 2008 (r48188) because it needed base pointer support to function correctly. This implementation follows the strategy suggested by Dale Johannesen in r48188 where the following comment was added: This does not currently work, because the delta between old and new stack pointers is added to offsets that reference incoming parameters after the prolog is generated, and the code that does that doesn't handle a variable delta. You don't want to do that anyway; a better approach is to reserve another register that retains to the incoming stack pointer, and reference parameters relative to that. And now we do exactly that. If we don't need a frame pointer, then we use r31 as a base pointer. If we do need a frame pointer, then we use r30 as a base pointer. The base pointer retains the value of the stack pointer before it was decremented in the prologue. We then use the base pointer to resolve all negative frame indicies. The basic scheme follows that for base pointers in the X86 backend. We use a base pointer when we need to dynamically realign the incoming stack pointer. This currently applies only to static objects (dynamic allocas with large alignments, and base-pointer support in SjLj lowering will come in future commits). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186478 91177308-0d34-0410-b5e6-96231b3b80d8
* PPCJITInfo.cpp: Tweak r186252 with s/__ppc/__powerpc/ to work on ↵NAKAMURA Takumi2013-07-161-2/+2
| | | | | | | | powerpc-linux Fedora 12. g++ (GCC) 4.4.4 20100630 (Red Hat 4.4.4-10) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186396 91177308-0d34-0410-b5e6-96231b3b80d8
* PPC: Refactoring to support subtarget feature changingHal Finkel2013-07-152-37/+69
| | | | | | | | | This change mirrors the changes that were made to the X86 and ARM targets to support subtarget feature changing. As indicated in r182899, the mechanism is still undergoing revision, and so as with the X86 and ARM targets, there is no test case yet (there is no effective functionality change). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186357 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix register subclass handling in PPCInstrInfo::insertSelectHal Finkel2013-07-151-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | PPCInstrInfo::insertSelect and PPCInstrInfo::canInsertSelect were computing the common subclass of the true and false inputs, and then selecting either the 32-bit or the 64-bit isel variant based on the result of calling PPC::GPRCRegClass.hasSubClassEq(RC) and PPC::G8RCRegClass.hasSubClassEq(RC) (where RC is the common subclass). Unfortunately, this is not quite right: if we have something like this: %vreg8<def> = SELECT_CC_I8 %vreg4<kill>, %vreg7<kill>, %vreg6<kill>, 76; G8RC_and_G8RC_NOX0:%vreg8 CRRC:%vreg4 G8RC_NOX0:%vreg7,%vreg6 then the common subclass of G8RC_and_G8RC_NOX0 and G8RC_NOX0 is G8RC_NOX0, and G8RC_NOX0 is not a subclass of G8RC (because it also contains the ZERO8 pseudo-register). As a result, we also need to check the common subclass against GPRC_NOR0 and G8RC_NOX0 explicitly. This had not been a problem for clients of insertSelect that called canInsertSelect first (because it had a compensating mistake), but insertSelect is also used by the PPC pseudo-instruction expander, and this error was causing a problem in that context. This problem was found by csmith. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186343 91177308-0d34-0410-b5e6-96231b3b80d8
* Use llvm::array_lengthof to replace sizeof(array)/sizeof(array[0]).Craig Topper2013-07-151-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186301 91177308-0d34-0410-b5e6-96231b3b80d8
* Use SmallVectorImpl& instead of SmallVector to avoid repeating small vector ↵Craig Topper2013-07-143-15/+15
| | | | | | size. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186274 91177308-0d34-0410-b5e6-96231b3b80d8
* Reduce large list of macros to the primary platform macros. DistingiushJoerg Sonnenberger2013-07-131-20/+18
| | | | | | | | between ELF (Linux, FreeBSD, NetBSD) and OSX as platform for the assembler dialect. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186252 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.1 at 2025-08-18 12:32:02 +0000