Commit Graph

3631 Commits

Author SHA1 Message Date
Charles Davis
5510728d28 Move everything depending on Object/MachOFormat.h over to Support/MachO.h.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189728 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-01 04:28:48 +00:00
Bill Schmidt
cda04f9a0a [PowerPC] Fast-isel cleanup patch.
Here are a few miscellaneous things to tidy up the PPC64 fast-isel
implementation.  I corrected a couple of commentary lapses, and added
documentation of future opportunities.  I also implemented
TargetMaterializeAlloca, which I somehow forgot when I split up the
original huge patch.

Finally, I decided to delete SelectCmp.  I hadn't previously hooked it
in to TargetSelectInstruction(), and when I did I realized it wasn't
serving any useful purpose.  This is only useful for compares that
don't feed a branch in the same block, and to handle that we would
have to have logic to interpret i1 as a condition register.  This
could probably be done, but would require Unseemly Hackery, and
honestly does not seem worth the hassle.

This ends the current patch series.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189715 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-31 02:33:40 +00:00
Bill Schmidt
9d2238cb0f [PowerPC] Add integer truncation support to fast-isel.
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
2013-08-30 23:31:33 +00:00
Bill Schmidt
9056dd45a4 Correct partially defined variable
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189705 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-30 23:25:30 +00:00
Bill Schmidt
11addd2a2f [PowerPC] Call support for fast-isel.
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
2013-08-30 22:18:55 +00:00
Bill Schmidt
9bc94276e7 [PowerPC] Add handling for conversions to fast-isel.
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
2013-08-30 15:18:11 +00:00
Bill Schmidt
e206efd39b [PowerPC] Handle selection of compare instructions in fast-isel.
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
2013-08-30 03:16:48 +00:00
Bill Schmidt
40433e5df9 Remove bogus debug statement. Sheesh.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189638 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-30 03:07:11 +00:00
Bill Schmidt
7248968fa5 [PowerPC] Add loads, stores, and related things to fast-isel.
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
2013-08-30 02:29:45 +00:00
Alexey Samsonov
ead2d5a4be Fix use of uninitialized value added in r189400 (found by MemorySanitizer)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189456 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-28 08:30:47 +00:00
Joerg Sonnenberger
66b7139b1b Given target assembler parsers a chance to handle variant expressions
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
2013-08-27 20:23:19 +00:00
Charles Davis
f69a29b23a Revert "Fix the build broken by r189315." and "Move everything depending on 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
2013-08-27 05:38:30 +00:00
Charles Davis
9c3dd1b0d1 Move everything depending on Object/MachOFormat.h over to Support/MachO.h.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189315 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-27 05:00:43 +00:00
Bill Schmidt
7c42ede045 Dummy code to silence warning from 4189266
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189272 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-26 20:11:46 +00:00
Bill Schmidt
055d207426 [PowerPC] More fast-isel chunks (returns and integer extends)
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
2013-08-26 19:42:51 +00:00
Bill Schmidt
3fad2bcd25 [PowerPC] Add fast-isel branch and compare selection.
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
2013-08-25 22:33:42 +00:00
Bill Schmidt
6af35e9576 [PowerPC] More refactoring prior to real PPC emitPrologue/Epilogue changes.
(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
2013-08-20 03:12:23 +00:00
Hal Finkel
66d1fa6f4b Add a llvm.copysign intrinsic
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
2013-08-19 23:35:46 +00:00
Hal Finkel
30cbccb029 Don't form PPC CTR-based loops around a copysignl call
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
2013-08-19 23:35:24 +00:00
Hal Finkel
953a78084b Add the PPC fcpsgn instruction
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
2013-08-19 05:01:02 +00:00
Bill Schmidt
9bb6c81683 [PowerPC] Preparatory refactoring for making prologue and epilogue
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
2013-08-16 20:05:04 +00:00
Craig Topper
5a0910b349 Replace getValueType().getSimpleVT() with getSimpleValueType(). Also remove 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
2013-08-15 02:33:50 +00:00
Hal Finkel
341c1a50ad Actually fix PPC64 64-bit GPR inline asm constraint matching
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
2013-08-14 20:05:04 +00:00
David Fang
d76adee1b2 cast fix to appease buildbot
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188014 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-08 21:29:30 +00:00
David Fang
d4f9d05fde initial draft of PPCMachObjectWriter.cpp
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
2013-08-08 20:14:40 +00:00
Hal Finkel
05a4d2642b PPC: Map frin to round() not nearbyint() and rint()
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
2013-08-08 04:31:34 +00:00
Hal Finkel
41418d17cc Add ISD::FROUND for libm round()
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
2013-08-07 22:49:12 +00:00
Hal Finkel
0e910d2cb5 Add PPC64 mulli pattern
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
2013-08-06 17:03:03 +00:00
NAKAMURA Takumi
8e1d64666f Target/*/CMakeLists.txt: Add the dependency to CommonTableGen explicitly for 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
2013-08-06 06:38:37 +00:00
Benjamin Kramer
af00feb1a6 PPCAsmParser: Stop leaking names.
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
2013-08-03 22:43:29 +00:00
Hal Finkel
5cad12d12a Fix PPC64 64-bit GPR inline asm constraint matching
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
2013-08-03 12:25:10 +00:00
Bill Wendling
61fc8d670f Use function attributes to indicate that we don't want to realign the stack.
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
2013-08-01 21:42:05 +00:00
Bill Schmidt
646cd7933b [PowerPC] Skeletal FastISel support for 64-bit PowerPC ELF.
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
2013-07-30 00:50:39 +00:00
Bill Schmidt
f5b9110ce1 [PowerPC] Add comment explaining preprocessor directive.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187320 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-28 03:23:32 +00:00
Bill Schmidt
eec21735b3 Revert 187318
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187319 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-28 02:13:24 +00:00
Bill Schmidt
8faa99081d [PowerPC] Remove unnecessary preprocessor checking.
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
2013-07-28 02:08:13 +00:00
Rafael Espindola
496cf2308a Revert "[PowerPC] Improve consistency in use of __ppc__, __powerpc__, etc."
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
2013-07-26 22:13:57 +00:00
Bill Schmidt
d063a326b2 [PowerPC] Improve consistency in use of __ppc__, __powerpc__, etc.
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
2013-07-26 21:39:15 +00:00
Bill Schmidt
f38cc38fa6 [PowerPC] Support powerpc64le as a syntax-checking target.
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
2013-07-26 01:35:43 +00:00
Roman Divacky
6ebf55d811 PPC32 va_list is an actual structure so va_copy needs to copy the whole
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
2013-07-25 21:36:47 +00:00
David Fang
ef540b194f allow tests to run on powerpc-darwin8 again, checking for __ppc__
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187027 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-24 07:52:16 +00:00
Craig Topper
f63ef914b6 Split generated asm mnemonic matching table into a separate table for each 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
2013-07-24 07:33:14 +00:00
Hal Finkel
aad2a72c28 PPC: Support dynamic allocas with large alignment
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
2013-07-18 04:28:21 +00:00
Hal Finkel
0541722de4 PPC: Add base-pointer support to builtin setjmp/longjmp
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
2013-07-17 23:50:51 +00:00
Hal Finkel
8d7435e9b1 PPC: Add CTR-register clobber to builtin setjmp
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
2013-07-17 05:35:44 +00:00
Hal Finkel
fe47bf8fa0 PPC: Implement base pointer and stack realignment
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
2013-07-17 00:45:52 +00:00
NAKAMURA Takumi
649c7fc474 PPCJITInfo.cpp: Tweak r186252 with s/__ppc/__powerpc/ to work on 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
2013-07-16 09:59:51 +00:00
Hal Finkel
a44c37f880 PPC: Refactoring to support subtarget feature changing
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
2013-07-15 22:29:40 +00:00
Hal Finkel
ae4f3f6820 Fix register subclass handling in PPCInstrInfo::insertSelect
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
2013-07-15 20:22:58 +00:00
Craig Topper
b9df53a40b Use llvm::array_lengthof to replace sizeof(array)/sizeof(array[0]).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186301 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-15 04:27:47 +00:00