| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
it at the moment.
This allows to form more paired loads even when stack coloring pass destroys the
memoryoperand's value.
<rdar://problem/13978317>
llvm-svn: 184492
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is another minor cleanup; to bring enum names in line
with the corresponding @modifier names, this renames:
VK_PPC_TOC -> VK_PPC_TOCBASE
VK_PPC_TOC_ENTRY -> VK_PPC_TOC16
No code change intended.
llvm-svn: 184491
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a bit tricky as the xacquire and xrelease hints use the same bytes,
0xf2 and 0xf3, as the repne and rep prefixes.
Fortunately llvm has different llvm MCInst Opcode enums for rep/xrelease
and repne/xacquire. So to make this work a boolean was added the
InternalInstruction struct as part of the Prefix state which is set with the
added logic in readPrefixes() when decoding an instruction to determine
if these prefix bytes are to be disassembled as xacquire or xrelease. Then
we let the matcher pick the normal prefix instructionID and we change the
Opcode after that when it is set into the MCInst being created.
rdar://11019859
llvm-svn: 184490
|
|
|
|
| |
llvm-svn: 184488
|
|
|
|
|
|
|
|
|
| |
This just re-sorts the big switch statement in
PPCELFObjectWriter::getRelocTypeInner to follow
the (numerical) order of the reloc types, and
fixes a couple of whitespace issues.
llvm-svn: 184485
|
|
|
|
| |
llvm-svn: 184484
|
|
|
|
|
|
|
|
|
|
| |
Also add a v2i32 test to the existing v4i32 test.
Patch by: Aaron Watry
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Aaron Watry<awatry@gmail.com>
llvm-svn: 184482
|
|
|
|
|
|
|
|
|
|
|
| |
Also add SI tests to existing file and a v2i32 test for both
R600 and SI.
Patch by: Aaron Watry
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 184481
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The custom lowering causes llc to crash with a segfault.
Ideally, the custom lowering can be fixed, but this allows
programs which load/store v2i32 to work without crashing.
Patch by: Aaron Watry
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Aaron Watry<awatry@gmail.com>
llvm-svn: 184480
|
|
|
|
| |
llvm-svn: 184478
|
|
|
|
|
|
|
|
|
| |
After this patch, the ELF file produced by
`yaml2obj-elf-symbol-basic.yaml`, when linked and executed on x86_64
(under SysV ABI, obviously; I tested on Linux), produces a working
executable that goes into an infinite loop!
llvm-svn: 184469
|
|
|
|
| |
llvm-svn: 184468
|
|
|
|
|
|
| |
With this we can remove the last use of PathV1 from llvm-ar.cpp.
llvm-svn: 184464
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Use that in llvm-ar.cpp to replace a use of sys::PathWithStatus.
llvm-svn: 184450
|
|
|
|
| |
llvm-svn: 184446
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
We collect gather sequences when we vectorize basic blocks. Gather sequences are excellent
hints for vectorization of other basic blocks.
llvm-svn: 184444
|
|
|
|
|
|
|
| |
The isDarwin parameter to the llvm::LowerPPCMachineInstrToMCInst
routine is now no longer needed; remove it.
llvm-svn: 184441
|
|
|
|
|
|
| |
This change makes it easier to filter debug messages.
llvm-svn: 184440
|
|
|
|
|
|
|
| |
This (hopefully) fixes build failures resulting from r184436;
the PowerPC asm parser now depends on PowerPC target expresssions.
llvm-svn: 184439
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
PR16389
llvm-svn: 184434
|
|
|
|
| |
llvm-svn: 184431
|
|
|
|
| |
llvm-svn: 184428
|
|
|
|
|
|
| |
registers.
llvm-svn: 184411
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function anyway
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 184376
|
|
|
|
| |
llvm-svn: 184373
|
|
|
|
|
|
| |
use it.
llvm-svn: 184369
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We had been papering over a problem with location info for non-trivial
types passed by value by emitting their type as references (this caused
the debugger to interpret the location information correctly, but broke
the type of the function). r183329 corrected the type information but
lead to the debugger interpreting the pointer parameter as the value -
the debug info describing the location needed an extra dereference.
Use a new flag in DIVariable to add the extra indirection (either by
promoting an existing DW_OP_reg (parameter passed in a register) to
DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n
(parameter passed on the stack).
llvm-svn: 184368
|
|
|
|
| |
llvm-svn: 184362
|
|
|
|
|
|
|
|
|
| |
This is a basic implementation - we still don't have any support (that I
know of) for dumping DWARF expressions in a meaningful way, so the
location information itself is just printed as a sequence of bytes as we
do elsewhere.
llvm-svn: 184361
|
|
|
|
|
|
| |
caching it. The TLI may change between functions. No functionality change.
llvm-svn: 184360
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The compiler occasionally generates multiple .loc directives in a row
(at the same instruction address). These need to be transformed into
multple actual .debug_line table entries, since they are used to signal
certain information to the debugger (e.g. if the opening brace of a
function body is on the same line as the declaration).
The MCAsmStreamer version of EmitDwarfLocDirective handles this
correctly by emitting a .loc directive every time it is called.
However, the MCObjectStream version simply defaults to recording
the information and emitting only a single table entry later,
e.g. when EmitInstruction is called.
This patch introduces a MCAsmStreamer::EmitDwarfLocDirective
version that emits a line table entry for a .loc directive
that may already be pending before recording the new directive.
(This is similar to how this is handled in GNU as.)
With this patch (and the code alignment factor patch) applied,
I'm now getting identical DWARF .debug sections for all test-suite
object files on PowerPC for the internal and the external assembler.
llvm-svn: 184357
|
|
|
|
|
|
|
|
| |
APFloat::isFiniteNonZero.
Turns out all the references were in llvm and not in clang.
llvm-svn: 184356
|
|
|
|
|
|
| |
caching it. The TLI may change between functions. No functionality change.
llvm-svn: 184352
|
|
|
|
|
|
| |
actually finds a unique identifier for a file. Also adds unit tests for GetUniqueID.
llvm-svn: 184351
|
|
|
|
|
|
| |
caching it. The TLI may change between functions. No functionality change.
llvm-svn: 184349
|
|
|
|
|
|
| |
already.
llvm-svn: 184346
|
|
|
|
| |
llvm-svn: 184344
|
|
|
|
|
|
| |
Register it with PassManager
llvm-svn: 184343
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this change, the considered addressing modes may be invalid since the
maximum and minimum offsets were not taking into account.
This was causing an assertion failure.
The added test case exercices that behavior.
<rdar://problem/14199725> Assertion failed: (CurScaleCost >= 0 && "Legal
addressing mode has an illegal cost!")
llvm-svn: 184341
|
|
|
|
|
|
| |
ExtractElementInst).
llvm-svn: 184325
|
|
|
|
|
|
|
|
| |
The type <3 x i8> is a common in graphics and we want to be able to vectorize it.
This changes accelerates bullet by 12% and 471_omnetpp by 5%.
llvm-svn: 184317
|
|
|
|
| |
llvm-svn: 184311
|
|
|
|
| |
llvm-svn: 184305
|