- Jun 20, 2013
-
-
Meador Inge authored
This commit completely removes what is left of the simplify-libcalls pass. All of the functionality has now been migrated to the instcombine and functionattrs passes. The following C API functions are now NOPs: 1. LLVMAddSimplifyLibCallsPass 2. LLVMPassManagerBuilderSetDisableSimplifyLibCalls llvm-svn: 184459
-
Sean Silva authored
llvm-svn: 184457
-
Sean Silva authored
llvm-svn: 184456
-
Rafael Espindola authored
llvm-svn: 184455
-
Michael Gottesman authored
[ReleaseNotes] Added bullet point stating that APFloat::isNormal() is now IEEE 754R-2008 compliant and that the relevant method renaming occurred. For more information see r184449, r184350, r184356, r184366. llvm-svn: 184452
-
Rafael Espindola authored
Use that in llvm-ar.cpp to replace a use of sys::PathWithStatus. llvm-svn: 184450
-
Michael Gottesman authored
The old isNormal is already functionally replaced by the method isFiniteNonZero in r184350 and all references to said method were replaced in LLVM/clang in r184356/134366. llvm-svn: 184449
-
Rafael Espindola authored
Matches gnu ar behavior. llvm-svn: 184448
-
Michael Gottesman authored
llvm-svn: 184447
-
Nadav Rotem authored
llvm-svn: 184446
-
Joey Gouly authored
The cdp2 instruction should have the same restrictions as cdp on the co-processor registers. VFP instructions on v8/AArch32 share the same encoding space as cdp2. llvm-svn: 184445
-
Nadav Rotem authored
We collect gather sequences when we vectorize basic blocks. Gather sequences are excellent hints for vectorization of other basic blocks. llvm-svn: 184444
-
David Blaikie authored
llvm-svn: 184443
-
Ulrich Weigand authored
[PowerPC] Remove unused parameter The isDarwin parameter to the llvm::LowerPPCMachineInstrToMCInst routine is now no longer needed; remove it. llvm-svn: 184441
-
Nadav Rotem authored
This change makes it easier to filter debug messages. llvm-svn: 184440
-
Ulrich Weigand authored
[PowerPC] Add missing build dependency This (hopefully) fixes build failures resulting from r184436; the PowerPC asm parser now depends on PowerPC target expresssions. llvm-svn: 184439
-
Ulrich Weigand authored
[MC] Support @ variants with directional labels The assembler parser common code supports recognizing symbol variants using the @ modifer. On PowerPC, it should also be possible to use (some of) those modifiers with directional labels, like "1f@l". This patch adds support for accepting symbol variants on directional labels as well. llvm-svn: 184437
-
Ulrich Weigand authored
[PowerPC] Optimize @ha/@l constructs This patch adds support for having the assembler optimize fixups to constructs like "symbol@ha" or "symbol@l" if "symbol" can be resolved at assembler time. This optimization is already present in the PPCMCExpr.cpp code for handling PPC_HA16/PPC_LO16 target expressions. However, those target expression were used only on Darwin targets. This patch changes target expression code so that they are usable also with the GNU assembler (using the @ha / @l syntax instead of the ha16() / lo16() syntax), and changes the MCInst lowering code to generate those target expressions where appropriate. It also changes the asm parser to generate HA16/LO16 target expressions when parsing assembler source that uses the @ha / @l modifiers. The effect is that now the above- mentioned optimization automatically becomes available for those situations too. llvm-svn: 184436
-
Ulrich Weigand authored
[PowerPC] Support compare mnemonics with implied CR0 Just like for branch mnemonics (where support was recently added), the assembler is supposed to support extended mnemonics for the compare instructions where no condition register is specified explicitly (and CR0 is assumed implicitly). This patch adds support for those extended compare mnemonics. Index: llvm-head/test/MC/PowerPC/ppc64-encoding-ext.s =================================================================== --- llvm-head.orig/test/MC/PowerPC/ppc64-encoding-ext.s +++ llvm-head/test/MC/PowerPC/ppc64-encoding-ext.s @@ -449,21 +449,37 @@ # CHECK: cmpdi 2, 3, 128 # encoding: [0x2d,0x23,0x00,0x80] cmpdi 2, 3, 128 +# CHECK: cmpdi 0, 3, 128 # encoding: [0x2c,0x23,0x00,0x80] + cmpdi 3, 128 # CHECK: cmpd 2, 3, 4 # encoding: [0x7d,0x23,0x20,0x00] cmpd 2, 3, 4 +# CHECK: cmpd 0, 3, 4 # encoding: [0x7c,0x23,0x20,0x00] + cmpd 3, 4 # CHECK: cmpldi 2, 3, 128 # encoding: [0x29,0x23,0x00,0x80] cmpldi 2, 3, 128 +# CHECK: cmpldi 0, 3, 128 # encoding: [0x28,0x23,0x00,0x80] + cmpldi 3, 128 # CHECK: cmpld 2, 3, 4 # encoding: [0x7d,0x23,0x20,0x40] cmpld 2, 3, 4 +# CHECK: cmpld 0, 3, 4 # encoding: [0x7c,0x23,0x20,0x40] + cmpld 3, 4 # CHECK: cmpwi 2, 3, 128 # encoding: [0x2d,0x03,0x00,0x80] cmpwi 2, 3, 128 +# CHECK: cmpwi 0, 3, 128 # encoding: [0x2c,0x03,0x00,0x80] + cmpwi 3, 128 # CHECK: cmpw 2, 3, 4 # encoding: [0x7d,0x03,0x20,0x00] cmpw 2, 3, 4 +# CHECK: cmpw 0, 3, 4 # encoding: [0x7c,0x03,0x20,0x00] + cmpw 3, 4 # CHECK: cmplwi 2, 3, 128 # encoding: [0x29,0x03,0x00,0x80] cmplwi 2, 3, 128 +# CHECK: cmplwi 0, 3, 128 # encoding: [0x28,0x03,0x00,0x80] + cmplwi 3, 128 # CHECK: cmplw 2, 3, 4 # encoding: [0x7d,0x03,0x20,0x40] cmplw 2, 3, 4 +# CHECK: cmplw 0, 3, 4 # encoding: [0x7c,0x03,0x20,0x40] + cmplw 3, 4 # FIXME: Trap mnemonics Index: llvm-head/lib/Target/PowerPC/PPCInstrInfo.td =================================================================== --- llvm-head.orig/lib/Target/PowerPC/PPCInstrInfo.td +++ llvm-head/lib/Target/PowerPC/PPCInstrInfo.td @@ -2201,3 +2201,12 @@ defm : BranchExtendedMnemonic<"ne", 68>; defm : BranchExtendedMnemonic<"nu", 100>; defm : BranchExtendedMnemonic<"ns", 100>; +def : InstAlias<"cmpwi $rA, $imm", (CMPWI CR0, gprc:$rA, s16imm:$imm)>; +def : InstAlias<"cmpw $rA, $rB", (CMPW CR0, gprc:$rA, gprc:$rB)>; +def : InstAlias<"cmplwi $rA, $imm", (CMPLWI CR0, gprc:$rA, u16imm:$imm)>; +def : InstAlias<"cmplw $rA, $rB", (CMPLW CR0, gprc:$rA, gprc:$rB)>; +def : InstAlias<"cmpdi $rA, $imm", (CMPDI CR0, g8rc:$rA, s16imm:$imm)>; +def : InstAlias<"cmpd $rA, $rB", (CMPD CR0, g8rc:$rA, g8rc:$rB)>; +def : InstAlias<"cmpldi $rA, $imm", (CMPLDI CR0, g8rc:$rA, u16imm:$imm)>; +def : InstAlias<"cmpld $rA, $rB", (CMPLD CR0, g8rc:$rA, g8rc:$rB)>; + llvm-svn: 184435
-
Evgeniy Stepanov authored
PR16389 llvm-svn: 184434
-
Rafael Espindola authored
llvm-svn: 184433
-
Rafael Espindola authored
llvm-svn: 184431
-
Evgeniy Stepanov authored
llvm-svn: 184428
-
Stefanus Du Toit authored
llvm-svn: 184426
-
Rafael Espindola authored
Should fix the bots that are seeing a corrupted file from a previous run. llvm-svn: 184424
-
Rafael Espindola authored
Original message: Don't include directory names in archives. This matches the behavior of both gnu and os x versions of ar. llvm-svn: 184423
-
Rafael Espindola authored
This reverts commit 184420. Investigating the bot failures. llvm-svn: 184421
-
Rafael Espindola authored
This matches the behavior of both gnu and os x versions of ar. llvm-svn: 184420
-
Rafael Espindola authored
llvm-svn: 184418
-
Rafael Espindola authored
llvm-svn: 184416
-
Rafael Espindola authored
llvm-svn: 184415
-
Rafael Espindola authored
llvm-svn: 184413
-
Rafael Espindola authored
llvm-svn: 184412
-
Vladimir Medic authored
llvm-svn: 184411
-
Bill Wendling authored
llvm-svn: 184400
-
David Blaikie authored
Fix up three tests - one that was relying on abbreviation number, another relying on a location list in this case (& testing raw asm, changed that to use dwarfdump on the debug_info now that that's where the location is), and another which was added in r184368 - exposing a bug in that fix that is exposed when we emit the location inline rather than through a location list. Fix that bug while I'm here. llvm-svn: 184387
-
Argyrios Kyrtzidis authored
[Support/CrashRecoveryContext] Make sure CrashRecoveryContext does not clear the thread-local "CurrentContext" in the "parent" thread, when we are using CrashRecoveryContext::RunSafelyOnThread. When using CrashRecoveryContext::RunSafelyOnThread, we would set a CrashRecoveryContextImpl* to a thread-local variable for the "child" thread, but CrashRecoveryContext would erroneously clear it in the "parent" thread. The result was that if CrashRecoveryContext::RunSafelyOnThread was called again in the "child" thread it would mess up crash-recovery for its parent. A test for this will be added in the clang repository. rdar://14204560 llvm-svn: 184380
-
Bill Wendling authored
llvm-svn: 184376
-
Bill Wendling authored
llvm-svn: 184375
-
Bill Wendling authored
llvm-svn: 184374
-