| dce4a407a24b04eebc6a376f8e62b41aaa7b071f |
|
29-May-2014 |
Stephen Hines <srhines@google.com> |
Update LLVM for 3.5 rebase (r209712).
Change-Id: I149556c940fb7dc92d075273c87ff584f400941f
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 36b56886974eae4f9c5ebc96befd3e7bfe5de338 |
|
24-Apr-2014 |
Stephen Hines <srhines@google.com> |
Update to LLVM 3.5a.
Change-Id: Ifadecab779f128e62e430c2b4f6ddd84953ed617
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 66d1fa6f4b443ac9f8bcea5d1f71a73ada733a42 |
|
20-Aug-2013 |
Hal Finkel <hfinkel@anl.gov> |
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
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 30cbccb029b01738202bd04341b1cbf68a7814c9 |
|
20-Aug-2013 |
Hal Finkel <hfinkel@anl.gov> |
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
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 41418d17cced656f91038b2482bc9d173b4974b0 |
|
08-Aug-2013 |
Hal Finkel <hfinkel@anl.gov> |
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
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 8d7435e9b1319c6e748a06c0b41a4c3de82ec750 |
|
17-Jul-2013 |
Hal Finkel <hfinkel@anl.gov> |
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
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 6227d5c690504c7ada5780c00a635b282c46e275 |
|
04-Jul-2013 |
Craig Topper <craig.topper@gmail.com> |
Use SmallVectorImpl::iterator/const_iterator instead of SmallVector to avoid specifying the vector size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185606 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| b5f7b0f9780cd1bc6f948b194adfc57176d41711 |
|
01-Jul-2013 |
Hal Finkel <hfinkel@anl.gov> |
Don't form PPC CTR loops for over-sized exit counts
Although you can't generate this from C on PPC64, if you have a loop using a
64-bit counter on PPC32 then you can't form a CTR-based loop for it. This had
been cauing the PPCCTRLoops pass to assert.
Thanks to Joerg Sonnenberger for providing a test case!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185361 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 40be73bed71a69853720a7f0609cb1f2f77dc3bd |
|
08-Jun-2013 |
Hal Finkel <hfinkel@anl.gov> |
Disallow i64 div/rem in PPC32 counter loops
On PPC32, [su]div,rem on i64 types are transformed into runtime library
function calls. As a result, they are not allowed in counter-based loops (the
counter-loops verification pass caught this error; this change fixes PR16169).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183581 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 4e6b24ffcfafbc0c5eda1bb89163ccd56f394fdf |
|
20-May-2013 |
Hal Finkel <hfinkel@anl.gov> |
Rename LoopSimplify.h to LoopUtils.h
As discussed, LoopUtils.h is a better name.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182314 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 08f92c98ac1cdb43ec35653536c89964401d936c |
|
20-May-2013 |
Hal Finkel <hfinkel@anl.gov> |
Remove copied preheader insertion logic from PPCCTRLoops
Now that the preheader insertion logic in LoopSimplify is externally exposed,
use it, and remove the copy-and-pasted version.
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182300 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 85c08b059ce4248ee739e756cf717a9b429e2ec2 |
|
20-May-2013 |
Hal Finkel <hfinkel@anl.gov> |
Rename PPC MTCTRse to MTCTRloop
As the pairing of this instruction form with the bdnz/bdz branches is now
enforced by the verification pass, make it clear from the name that these
are used only for counter-based loops.
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182296 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| e50c8c1f81a38f0ecebafa5dc60a163814a9713a |
|
20-May-2013 |
Hal Finkel <hfinkel@anl.gov> |
Add a PPCCTRLoops verification pass
When asserts are enabled, this adds a verification pass for PPC counter-loop
formation. Unfortunately, without sacrificing code quality, there is no better
way of forming counter-based loops except at the (late) IR level. This means
that we need to recognize, at the IR level, anything which might turn into a
function call (or indirect branch). Because this is currently a finite set of
things, and because SelectionDAG lowering is basic-block local, this can be
done. Nevertheless, it is fragile, and failure results in a miscompile. This
verification pass checks that all (reachable) counter-based branches are
dominated by a loop mtctr instruction, and that no instructions in between
clobber the counter register. If these conditions are not satisfied, then an
ICE will be triggered.
In short, this is to help us sleep better at night.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182295 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| bf0bc3b2a2e11ff7e79b881ca82324fe17919a97 |
|
18-May-2013 |
Hal Finkel <hfinkel@anl.gov> |
Check InlineAsm clobbers in PPCCTRLoops
We don't need to reject all inline asm as using the counter register (most does
not). Only those that explicitly clobber the counter register need to prevent
the transformation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182191 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| c482454e3cc2a33a2cf2d1cf0881c7c5e2641c80 |
|
16-May-2013 |
Hal Finkel <hfinkel@anl.gov> |
Create an new preheader in PPCCTRLoops to avoid counter register clobbers
Some IR-level instructions (such as FP <-> i64 conversions) are not chained
w.r.t. the mtctr intrinsic and yet may become function calls that clobber the
counter register. At the selection-DAG level, these might be reordered with the
mtctr intrinsic causing miscompiles. To avoid this situation, if an existing
preheader has instructions that might use the counter register, create a new
preheader for the mtctr intrinsic. This extra block will be remerged with the
old preheader at the MI level, but will prevent unwanted reordering at the
selection-DAG level.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182045 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 2a5e8c328eb0d957f00190c0c6189a4f1fef1117 |
|
16-May-2013 |
Hal Finkel <hfinkel@anl.gov> |
PPC32 cannot form counter loops around i64 FP conversions
On PPC32, i64 FP conversions are implemented using runtime calls (which clobber
the counter register). These must be excluded.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182023 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| f1e7ea43aa3b511ea9750c7a1f721d1c683e31b2 |
|
16-May-2013 |
Hal Finkel <hfinkel@anl.gov> |
undef setjmp in PPCCTRLoops
Trying to unbreak the VS build by copying some undef code from
Utils/LowerInvoke.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181938 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| b1fd3cd78f8acd21dbf514b75fef991827c343b6 |
|
15-May-2013 |
Hal Finkel <hfinkel@anl.gov> |
Implement PPC counter loops as a late IR-level pass
The old PPCCTRLoops pass, like the Hexagon pass version from which it was
derived, could only handle some simple loops in canonical form. We cannot
directly adapt the new Hexagon hardware loops pass, however, because the
Hexagon pass contains a fundamental assumption that non-constant-trip-count
loops will contain a guard, and this is not always true (the result being that
incorrect negative counts can be generated). With this commit, we replace the
pass with a late IR-level pass which makes use of SE to calculate the
backedge-taken counts and safely generate the loop-count expressions (including
any necessary max() parts). This IR level pass inserts custom intrinsics that
are lowered into the desired decrement-and-branch instructions.
The most fragile part of this new implementation is that interfering uses of
the counter register must be detected on the IR level (and, on PPC, this also
includes any indirect branches in addition to function calls). Also, to make
all of this work, we need a variant of the mtctr instruction that is marked
as having side effects. Without this, machine-code level CSE, DCE, etc.
illegally transform the resulting code. Hopefully, this can be improved
in the future.
This new pass is smaller than the original (and much smaller than the new
Hexagon hardware loops pass), and can handle many additional cases correctly.
In addition, the preheader-creation code has been copied from LoopSimplify, and
after we decide on where it belongs, this code will be refactored so that it
can be explicitly shared (making this implementation even smaller).
The new test-case files ctrloop-{le,lt,ne}.ll have been adapted from tests for
the new Hexagon pass. There are a few classes of loops that this pass does not
transform (noted by FIXMEs in the files), but these deficiencies can be
addressed within the SE infrastructure (thus helping many other passes as well).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181927 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 3ea1b064a0b9c3d161b0f77a9e957970f98907ab |
|
22-Mar-2013 |
Hal Finkel <hfinkel@anl.gov> |
Fix a register-class comparison bug in PPCCTRLoops
Thanks to Jakob for isolating the underlying problem from the
test case in r177423. The original commit had introduced
asymmetric copy operations, but these turned out to be a work-around
to the real problem (the use of == instead of hasSubClassEq in PPCCTRLoops).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177679 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 9f2518cdc6321d8cfb16973654df2996bad8ad78 |
|
19-Mar-2013 |
Hal Finkel <hfinkel@anl.gov> |
Fix a sign-extension bug in PPCCTRLoops
Don't sign extend the immediate value from the OR instruction in
an LIS/OR pair.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177361 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| e39b107c468affd0aafa719edce67717cbb4bbec |
|
18-Mar-2013 |
Hal Finkel <hfinkel@anl.gov> |
Fix 80-col. violations in PPCCTRLoops
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177296 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 9887ec31e630ede8541dee1d90c44a1efb63c417 |
|
18-Mar-2013 |
Hal Finkel <hfinkel@anl.gov> |
Fix large count and negative constant count handling in PPCCTRLoops
This commit fixes an assert that would occur on loops with large constant counts
(like looping for ((uint32_t) -1) iterations on PPC64). The existing code did
not handle counts that it computed to be negative (asserting instead), but
these can be created with valid inputs.
This bug was discovered by bugpoint while I was attempting to isolate a
completely different problem.
Also, in writing test cases for the negative-count problem, I discovered that
the ori/lsi handling was broken (there was a typo which caused the logic that
was supposed to detect these pairs and extract the iteration count to always
fail). This has now also been corrected (and is covered by one of the new test
cases).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177295 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 1448d06156728712f47e5a71fac8e8edc0aba73b |
|
18-Mar-2013 |
Hal Finkel <hfinkel@anl.gov> |
Cleanup initial-value constants in PPCCTRLoops
Because the initial-value constants had not been added to the list
of instructions considered for DCE the resulting code had redundant
constant-materialization instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177294 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 96848dfc465c8c7f156a562c246803ebefcf21cf |
|
13-Feb-2013 |
Krzysztof Parzyszek <kparzysz@codeaurora.org> |
Add registration for PPC-specific passes to allow the IR to be dumped
via -print-after-all.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175058 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 0b8c9a80f20772c3793201ab5b251d3520b9cea3 |
|
02-Jan-2013 |
Chandler Carruth <chandlerc@gmail.com> |
Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| d04a8d4b33ff316ca4cf961e06c9e312eff8e64f |
|
03-Dec-2012 |
Chandler Carruth <chandlerc@gmail.com> |
Use the new script to sort the includes of every file under lib.
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 0c5f5f4916a5c72b2a6a9cb13f0b2c2add95b6f1 |
|
09-Aug-2012 |
Jakob Stoklund Olesen <stoklund@2pi.dk> |
Don't use getNextOperandForReg().
This way of using getNextOperandForReg() was unlikely to work as
intended. We don't give any guarantees about the order of operands in
the use-def chains, so looking only at operands following a given
operand in the chain doesn't make sense.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161542 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 2741d2cfdff89e45c6b98cd520d5cd3fe97829ad |
|
16-Jun-2012 |
Hal Finkel <hfinkel@anl.gov> |
Cleanup trip-count finding for PPC CTR loops (and some bug fixes).
This cleans up the method used to find trip counts in order to form CTR loops on PPC.
This refactoring allows the pass to find loops which have a constant trip count but also
happen to end with a comparison to zero. This also adds explicit FIXMEs to mark two different
classes of loops that are currently ignored.
In addition, we now search through all potential induction operations instead of just the first.
Also, we check the predicate code on the conditional branch and abort the transformation if the
code is not EQ or NE, and we then make sure that the branch to be transformed matches the
condition register defined by the comparison (multiple possible comparisons will be considered).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158607 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| daa03ec60475a641bcc66799764977f79997ca45 |
|
08-Jun-2012 |
Hal Finkel <hfinkel@anl.gov> |
Fix a bug in the new PPC CTR-Loops pass.
The code which tests for an induction operation cannot assume that any
ADDI instruction will have a register operand because the operand could
also be a frame index; for example:
%vreg16<def> = ADDI8 <fi#0>, 0; G8RC:%vreg16
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158205 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|
| 99f823f94374917174f96a7689955b8463db6816 |
|
08-Jun-2012 |
Hal Finkel <hfinkel@anl.gov> |
Add the PPCCTRLoops pass: a PPC machine-code-level optimization pass to form CTR-based loop branching code.
This pass is derived from the Hexagon HardwareLoops pass. The only significant enhancement over the Hexagon
pass is that PPCCTRLoops will also attempt to delete the replaced add and compare operations if they are
no longer otherwise used. Also, invalid preheader DebugLoc is not used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158204 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp
|