llvm/test/CodeGen/PowerPC, branch release_27http://llvm.orghttps://git.amat.us/llvm/atom/test/CodeGen/PowerPC?h=release_272010-02-28T20:36:49Zadd some random nounwinds.2010-02-28T20:36:49ZChris Lattnersabre@nondot.org2010-02-28T20:36:49Zurn:sha1:f70cbb2d6a9d2783d581ef7b5fdefd1b305ce332
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97411 91177308-0d34-0410-b5e6-96231b3b80d8
Use the right floating point load/store instructions in PPCInstrInfo::foldMemoryOperandImpl().2010-02-26T21:09:24ZJakob Stoklund Olesenstoklund@2pi.dk2010-02-26T21:09:24Zurn:sha1:243296690ec78fc918762bd73896b09e26537f47
The PowerPC floating point registers can represent both f32 and f64 via the
two register classes F4RC and F8RC. F8RC is considered a subclass of F4RC to
allow cross-class coalescing. This coalescing only affects whether registers
are spilled as f32 or f64.
Spill slots must be accessed with load/store instructions corresponding to the
class of the spilled register. PPCInstrInfo::foldMemoryOperandImpl was looking
at the instruction opcode which is wrong.
X86 has similar floating point register classes, but doesn't try to fold
memory operands, so there is no problem there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97262 91177308-0d34-0410-b5e6-96231b3b80d8
Change the scheduler from adding nodes in allnodes order2010-02-24T06:11:37ZChris Lattnersabre@nondot.org2010-02-24T06:11:37Zurn:sha1:736a6ea3a2a5322db0e09d97651a1acc07502e41
to adding them in a determinstic order (bottom up from
the root) based on the structure of the graph itself.
This updates tests for some random changes, interesting
bits: CodeGen/Blackfin/promote-logic.ll no longer crashes.
I have no idea why, but that's good right?
CodeGen/X86/2009-07-16-LoadFoldingBug.ll also fails, but
now compiles to have one fewer constant pool entry, making
the expected load that was being folded disappear. Since it
is an unreduced mass of gnast, I just removed it.
This fixes PR6370
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97023 91177308-0d34-0410-b5e6-96231b3b80d8
When emitting an instruction which depends on both a post-incremented2010-02-22T03:59:54ZDan Gohmangohman@apple.com2010-02-22T03:59:54Zurn:sha1:278f958c61e973975bf63b7a82f3d8322ea16c00
induction variable value and a loop-variant value, don't force the
insert position to be at the post-increment position, because it may
not be dominated by the loop-variant value. This fixes a
use-before-def problem noticed on PPC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96774 91177308-0d34-0410-b5e6-96231b3b80d8
add some no-unwinds, other minor cleanups.2010-02-21T20:33:20ZChris Lattnersabre@nondot.org2010-02-21T20:33:20Zurn:sha1:728ea19ece48ad848238bb940c2725c4de52933e
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96756 91177308-0d34-0410-b5e6-96231b3b80d8
add a triple so that this doesn't fail due to linux/ppc register printing 2010-02-21T19:27:38ZChris Lattnersabre@nondot.org2010-02-21T19:27:38Zurn:sha1:25e0f91d059fc59ce44aac07b0d136d6291c821f
syntax.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96748 91177308-0d34-0410-b5e6-96231b3b80d8
filecheckize and add nouwinds.2010-02-21T18:53:28ZChris Lattnersabre@nondot.org2010-02-21T18:53:28Zurn:sha1:ad14fcc4c2b0e6cb46549f2ac9cf42e54713cc4e
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96745 91177308-0d34-0410-b5e6-96231b3b80d8
Make g5 target explicit; scheduling affects register choice.2010-02-16T23:25:23ZDale Johannesendalej@apple.com2010-02-16T23:25:23Zurn:sha1:4a12de72b050f9276d2027fc9f7a29fc30af5cec
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96413 91177308-0d34-0410-b5e6-96231b3b80d8
Adjust register numbers in tests to compensate for the2010-02-16T22:31:31ZDale Johannesendalej@apple.com2010-02-16T22:31:31Zurn:sha1:55f9adf543156f918bebcab3924d4210099e20af
new lack of R2.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96407 91177308-0d34-0410-b5e6-96231b3b80d8
When save/restoring CR at prolog/epilog, in a large2010-02-12T21:35:34ZDale Johannesendalej@apple.com2010-02-12T21:35:34Zurn:sha1:c12da8d30a1394847ee4608fcd54daa24b889b37
stack frame, the prolog/epilog code was using the same
register for the copy of CR and the address of the save slot. Oops.
This is fixed here for Darwin, sort of, by reserving R2 for this case.
A better way would be to do the store before the decrement of SP,
which is safe on Darwin due to the red zone.
SVR4 probably has the same problem, but I don't know how to fix it;
there is no red zone and R2 is already used for something else.
I'm going to leave it to someone interested in that target.
Better still would be to rewrite the CR-saving code completely;
spilling each CR subregister individually is horrible code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96015 91177308-0d34-0410-b5e6-96231b3b80d8