summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert "R600: Move code for generating REGISTER_LOAD into R600ISelLowering.cpp"Tom Stellard2014-08-012-42/+37
| | | | | | | | This reverts commit r214566. I did not mean to commit this yet. llvm-svn: 214572
* BitcodeReader: Change mechanics of BlockAddress forward references, NFCDuncan P. N. Exon Smith2014-08-012-38/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we can reliably handle forward references to `BlockAddress` (r214563), change the mechanics to simplify predicting use-list order. Previously, we created dummy `GlobalVariable`s to represent block addresses. After every function was materialized, we'd go through any forward references to its blocks and RAUW them with a proper `BlockAddress` constant. This causes some (potentially a lot of) unnecessary use-list churn, since any constant expression that it's a part of will need to be rematerialized as well. Instead, pre-construct a `BasicBlock` immediately -- without attaching it to its (empty) `Function` -- and use that to construct a `BlockAddress`. This constant will not have to be regenerated. When the function body is parsed, hook this pre-constructed basic block up in the right place using `BasicBlock::insertInto()`. Both before and after this change, the IR is temporarily in an invalid state that gets resolved when `materializeForwardReferencedFunctions()` gets called. This is a prep commit that's part of PR5680, but the only functionality change is the reduction of churn in the constant pool. llvm-svn: 214570
* R600/SI: Remove leftover debugging codeTom Stellard2014-08-011-2/+0
| | | | llvm-svn: 214569
* R600: Move code for generating REGISTER_LOAD into R600ISelLowering.cppTom Stellard2014-08-012-37/+42
| | | | | | | SI doesn't use REGISTER_LOAD anymore, but it was still hitting this code path for 8-bit and 16-bit private loads. llvm-svn: 214566
* IR: Add BasicBlock::insertInto()Duncan P. N. Exon Smith2014-08-011-6/+13
| | | | | | | | | | | | | | | | | | | Although unlinked `BasicBlock`s can be created, there's currently no way to insert them into `Function`s after the fact. In particular, `moveAfter()` and `moveBefore()` require that the basic block is already linked. Extract the logic for initially linking a `BasicBlock` out of the constructor and into a member function that can be used for lazy insertion. - Asserts that the basic block is currently unlinked. - Matches the logic of the constructor. - Changed the constructor to use it since the logic matches. This is needed in a follow-up commit for PR5680. llvm-svn: 214563
* [dfsan] Correctly handle loads and stores of zero size.Peter Collingbourne2014-08-011-0/+8
| | | | llvm-svn: 214561
* Add a non-const subtarget returning function to the target machineEric Christopher2014-08-015-5/+16
| | | | | | | | | so that we can use it to get the old-style JIT out of the subtarget. This code should be removed when the old-style JIT is removed (imminently). llvm-svn: 214560
* BitcodeReader: Fix some BlockAddress forward reference corner casesDuncan P. N. Exon Smith2014-08-012-9/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | `BlockAddress`es are interesting in that they can reference basic blocks from *outside* the block's function. Since basic blocks are not global values, this presents particular challenges for lazy parsing. One corner case was found in PR11677 and fixed in r147425. In that case, a global variable references a block address. It's necessary to load the relevant function to resolve the forward reference before doing anything with the module. By inspection, I found (and have fixed here) two other cases: - An instruction from one function references a block address from another function, and only the first function is lazily loaded. I fixed this the same way as PR11677: by eagerly loading the referenced function. - A function whose block address is taken is dematerialized, leaving invalid references to it. I fixed this by refusing to dematerialize functions whose block addresses are taken (if you have to load it, you can't unload it). llvm-svn: 214559
* MS inline asm: Use memory constraints for functions instead of registersReid Kleckner2014-08-011-9/+21
| | | | | | | | | | | | | | | | | | | | | | This is consistent with how we parse them in a standalone .s file, and inline assembly shouldn't differ. This fixes errors about requiring more registers than available in cases like this: void f(); void __declspec(naked) g() { __asm pusha __asm call f __asm popa __asm ret } There are no registers available to pass the address of 'f' into the asm blob. The asm should now directly call 'f'. Tests will land in Clang shortly. llvm-svn: 214550
* [SDAG] Begin simplifying the way in which the legalizer deletes nodes.Chandler Carruth2014-08-011-41/+25
| | | | | | | | | | | | | | | | | | | | This lifts the (very few) places the legalizer would delete dead nodes into the outer loop around the legalizer. This is significantly simpler because it doesn't require the legalizer itself to manage the iterator validity, and it doesn't require the legalizer to be a DAG update listener in order to remove things from the legalized set. It also makes the interface much less contrived for the case of the legalizer running inside the last phase of DAG combining. I'm working on centralizing the deletion of nodes during both legalizing and combining as much as possible. My hope is to remove the need for DAG update listeners from the combiner next, which would remove a costly virtual dispatch chain on every deletion. This in turn should allow us to more aggressively delete DAG nodes during combining which will in turn allow us to combine more aggressively by exposing the actual nodes which have single users to the combine phases. llvm-svn: 214546
* [FastISel][AArch64] Fold offset into the memory operation.Juergen Ributzka2014-08-011-0/+7
| | | | | | | | | | | | Fold simple offsets into the memory operation: add x0, x0, #8 ldr x0, [x0] --> ldr x0, [x0, #8] Fixes <rdar://problem/17887945>. llvm-svn: 214545
* Include Archive.hRafael Espindola2014-08-011-0/+1
| | | | | | MSVC was complaining about Archive being an incomplete type. llvm-svn: 214542
* Move virtual method out of line.Rafael Espindola2014-08-011-0/+4
| | | | | | Should fix the MSVC build. llvm-svn: 214539
* Add support for StackMap section for ELF/Linux systemsPhilip Reames2014-08-012-0/+8
| | | | | | | | | | This patch adds code to emits the StackMap section on ELF systems. This section is required to support llvm.experimental.stackmap and llvm.experimental.patchpoint intrinsics. Reviewers: ributzka, echristo Differential Revision: http://reviews.llvm.org/D4574 llvm-svn: 214538
* [FastISel][AArch64] Add branch weights.Juergen Ributzka2014-08-011-5/+38
| | | | | | | | | Add branch weights to branch instructions, so that the following passes can optimize based on it (i.e. basic block ordering). Fixes <rdar://problem/17887137>. llvm-svn: 214537
* Explicitly report runtime stack realignment in StackMap sectionPhilip Reames2014-08-011-1/+4
| | | | | | | | | | | | This change adds code to explicitly mark a function which requires runtime stack realignment as not having a fixed frame size in the StackMap section. As it happens, this is not actually a functional change. The size that would be reported without the check is also "-1", but as far as I can tell, that's an accident. The code change makes this explicit. Note: There's a separate bug in handling of stackmaps and patchpoints in functions which need dynamic frame realignment. The current code assumes that offsets can be calculated from RBP, but realigned frames must use RSP. (There's a variable gap between RBP and the spill slots.) This change set does not address that issue. Reviewers: atrick, ributzka Differential Revision: http://reviews.llvm.org/D4572 llvm-svn: 214534
* Replace comment about ownership with std::unique_ptr.Rafael Espindola2014-08-012-9/+5
| | | | llvm-svn: 214533
* [FastISel][ARM] Do not emit stores for undef arguments.Juergen Ributzka2014-08-011-0/+6
| | | | | | | | This is a followup patch for r214366, which added the same behavior to the AArch64 and X86 FastISel code. This fix reproduces the already existing behavior of SelectionDAG in FastISel. llvm-svn: 214531
* Use range loop.Rafael Espindola2014-08-011-7/+3
| | | | llvm-svn: 214530
* Add missing breaks to AArch64InstrInfo::isGPRCopyRenato Golin2014-08-011-0/+3
| | | | llvm-svn: 214528
* R600/SI: Don't display GDS bit for read2Matt Arsenault2014-08-011-1/+1
| | | | | | | This isn't displayed for any other instructions anymore, and isn't ever used. llvm-svn: 214523
* [AArch64] Generate tbz/tbnz when comparing against zero.Chad Rosier2014-08-011-10/+16
| | | | | | | | | | | | | | | | | The tbz/tbnz checks the sign bit to convert op w1, w1, w10 cmp w1, #0 b.lt .LBB0_0 to op w1, w1, w10 tbnz w1, #31, .LBB0_0 Differential Revision: http://reviews.llvm.org/D4440 llvm-svn: 214518
* [PowerPC] PR20280 - Slots for byval parameters are not immutableUlrich Weigand2014-08-011-1/+1
| | | | | | | | | Found by inspection while looking at PR20280: code would mark slots in the parameter save area where a byval parameter is passed as "immutable". This is not correct since code is allowed to modify byval parameters in place in the parameter save area. llvm-svn: 214517
* Remove some calls to std::move.Rafael Espindola2014-08-015-16/+16
| | | | | | | | | Instead of moving out the data in a ErrorOr<std::unique_ptr<Foo>>, get a reference to it. Thanks to David Blaikie for the suggestion. llvm-svn: 214516
* [pr20127] Check for leading \1 in the Twine version of getNameWithPrefix.Rafael Espindola2014-08-011-8/+8
| | | | | | | No functionality change, but will simplify an upcoming patch that uses the Twine version. llvm-svn: 214515
* Allow only disassembling of M-class MSR masks that the assembler knows how ↵James Molloy2014-08-011-1/+47
| | | | | | | | | | to assemble back. Note: The current code in DecodeMSRMask() rejects the unpredictable A/R MSR mask '0000' with Fail. The code in the patch follows this style and rejects unpredictable M-class MSR masks also with Fail (instead of SoftFail). If SoftFail is preferred in this case then additional changes to ARMInstPrinter (to print non-symbolic masks) and ARMAsmParser (to parse non-symbolic masks) will be needed. Patch by Petr Pavlu! llvm-svn: 214505
* Improve some const-correctness to remove a -Wcast-qual warning. No ↵Aaron Ballman2014-08-013-4/+5
| | | | | | functional changes intended. llvm-svn: 214503
* [ARM] Make the assembler reject unpredictable pre/post-indexed ARM ↵Tilmann Scheller2014-08-011-1/+7
| | | | | | | | LDRB/LDRSB instructions. The ARM ARM prohibits LDRB/LDRSB instructions with writeback into the destination register. With this commit this constraint is now enforced and we stop assembling LDRH/LDRSH instructions with unpredictable behavior. llvm-svn: 214500
* [ARM] Make the assembler reject unpredictable pre/post-indexed ARM ↵Tilmann Scheller2014-08-011-1/+5
| | | | | | | | LDRH/LDRSH instructions. The ARM ARM prohibits LDRH/LDRSH instructions with writeback into the source register. With this commit this constraint is now enforced and we stop assembling LDRH/LDRSH instructions with unpredictable behavior. llvm-svn: 214499
* [ARM] Make the assembler reject unpredictable pre/post-indexed ARM LDR ↵Tilmann Scheller2014-08-011-0/+13
| | | | | | | | instructions. The ARM ARM prohibits LDR instructions with writeback into the destination register. With this commit this constraint is now enforced and we stop assembling LDR instructions with unpredictable behavior. llvm-svn: 214498
* SLPVectorizer: fix build problem in Release configurationErik Eckstein2014-08-011-1/+5
| | | | llvm-svn: 214496
* SLPVectorizer: improved scheduling algorithm.Erik Eckstein2014-08-011-249/+693
| | | | llvm-svn: 214494
* [mips][PR19612] Fix va_arg for big-endian mode.Daniel Sanders2014-08-012-2/+68
| | | | | | | | | | | | | | | | | | Summary: Big-endian mode was not correctly adjusting the offset for types smaller than an ABI slot. Fixes PR19612 Reviewers: dsanders Reviewed By: dsanders Subscribers: sstankovic, llvm-commits Differential Revision: http://reviews.llvm.org/D4556 llvm-svn: 214493
* SLP Vectorizer: added statistics counterErik Eckstein2014-08-011-0/+12
| | | | llvm-svn: 214487
* SLP Vectorizer: improve canonicalize tree operands of commutitive binary ↵Erik Eckstein2014-08-011-28/+41
| | | | | | | | operands. This reverts r214338 (except the test file) and replaces it with a more general algorithm. llvm-svn: 214485
* [PowerPC] Generate unaligned vector loads using intrinsics instead of ↵Hal Finkel2014-08-012-52/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | regular loads Altivec vector loads on PowerPC have an interesting property: They always load from an aligned address (by rounding down the address actually provided if necessary). In order to generate an actual unaligned load, you can generate two load instructions, one with the original address, one offset by one vector length, and use a special permutation to extract the bytes desired. When this was originally implemented, I generated these two loads using regular ISD::LOAD nodes, now marked as aligned. Unfortunately, there is a problem with this: The alignment of a load does not contribute to its identity, and SDNodes are uniqued. So, imagine that we have some unaligned load, L1, that is not aligned. The routine will create two loads, L1(aligned) and (L1+16)(aligned). Further imagine that there had already existed a load (L1+16)(unaligned) with the same chain operand as the load L1. When (L1+16)(aligned) is created as part of the lowering of L1, this load *is* also the (L1+16)(unaligned) node, just now marked as aligned (because the new alignment overwrites the old). But the original users of (L1+16)(unaligned) now get the data intended for the permutation yielding the data for L1, and (L1+16)(unaligned) no longer exists to get its own permutation-based expansion. This was PR19991. A second potential problem has to do with the MMOs on these loads, which can be used by AA during instruction scheduling to break chain-based dependencies. If the new "aligned" loads get the MMO from the original unaligned load, this does not represent the fact that it will load data from below the original address. Normally, this would not matter, but this load might be combined with another load pair for a previous vector, and then the dependency on the otherwise- ignored lower bytes can matter. To fix both problems, instead of generating the necessary loads using regular ISD::LOAD instructions, ppc_altivec_lvx intrinsics are used instead. These are provided with MMOs with a conservative address range. Unfortunately, I no longer have a failing test case (since PR19991 was reported, other changes in CodeGen have forced this bug back into hiding it again). Nevertheless, this should fix the underlying problem. llvm-svn: 214481
* This patch implements transform for pattern "(A & ~B) ^ (~A) -> ~(A & B)".Suyog Sarda2014-08-011-0/+5
| | | | | | Differential Revision: http://reviews.llvm.org/D4653 llvm-svn: 214479
* This patch implements transform for pattern "(A | B) & ((~A) ^ B) -> (A & B)".Suyog Sarda2014-08-011-0/+10
| | | | | | Differential Revision: http://reviews.llvm.org/D4628 llvm-svn: 214478
* This patch implements transform for pattern "( A & (~B)) | (A ^ B) -> (A ^ B)"Suyog Sarda2014-08-011-0/+10
| | | | | | Differential Revision: http://reviews.llvm.org/D4652 llvm-svn: 214477
* This patch implements transform for pattern "(A & B) | ((~A) ^ B) -> (~A ^ B)".Suyog Sarda2014-08-011-0/+10
| | | | | | | | Patch Credit to Ankit Jain ! Differential Revision: http://reviews.llvm.org/D4655 llvm-svn: 214476
* R600/SI: Fix build warningTom Stellard2014-08-011-1/+1
| | | | llvm-svn: 214475
* [FastISel][AArch64] Fix the immediate versions of the ↵Juergen Ributzka2014-08-011-48/+49
| | | | | | | | | | | | {s|u}{add|sub}.with.overflow intrinsics. ADDS and SUBS cannot encode negative immediates or immediates larger than 12bit. This fix checks if the immediate version can be used under this constraints and if we can convert ADDS to SUBS or vice versa to support negative immediates. Also update the test cases to test the immediate versions. llvm-svn: 214470
* [PowerPC] Recognize consecutive memory accesses from intrinsicsHal Finkel2014-08-011-9/+63
| | | | | | | | | | | | | | | When generating unaligned vector loads, we need to search for other loads or stores nearby offset by one vector width. If we find one, then we know that we can safely generate another aligned load at that address. Otherwise, we must generate the next load using an offset of the vector width minus one byte (so we don't read off the end of the allocation if the base unaligned address happened to be aligned at runtime). We had previously done this using only other vector loads and stores, but did not consider the PowerPC-specific vector load/store intrinsics. Now we'll also consider vector intrinsics. By itself, this change is a feature enhancement, but is a necessary step toward fixing the underlying problem behind PR19991. llvm-svn: 214469
* MS inline asm: Fix null SMLoc when 'ptr' is missing after dword & coReid Kleckner2014-08-011-1/+1
| | | | | | | | This improves the diagnostics from the regular assembler, but more importantly it fixes an assertion when parsing inline assembly. Test landing in Clang. llvm-svn: 214468
* R600/SI: Do abs/neg folding with ComplexPatternsTom Stellard2014-08-0111-658/+1034
| | | | | | | | | | Abs/neg folding has moved out of foldOperands and into the instruction selection phase using complex patterns. As a consequence of this change, we now prefer to select the 64-bit encoding for most instructions and the modifier operands have been dropped from integer VOP3 instructions. llvm-svn: 214467
* R600/SI: Simplify and fix handling of VOP2 in SIInstrInfo::legalizeOperandsTom Stellard2014-08-012-28/+53
| | | | | | | | | | | | We were incorrectly assuming that all VOP2 instructions can read SGPRs in Src0, but this is not true for instructions that read carry-in from VCC. The old logic has been replaced with new logic which checks the defined register classes of the VOP2 instruction to determine whether or not to legalize the operands. llvm-svn: 214465
* R600/SI: Fold immediates when shrinking instructionsTom Stellard2014-08-013-12/+79
| | | | | | | This will prevent us from using extra MOV instructions once we prefer selecting 64-bit instructions. llvm-svn: 214464
* R600/SI: Fix incorrect commute operation in shrink instructions passTom Stellard2014-08-013-3/+16
| | | | | | | | We were commuting the instruction by still shrinking it using the original opcode. NOTE: This is a candidate for the 3.5 branch. llvm-svn: 214463
* Add support for the X86 secure guard extensions instructions in assembler (SGX).Kevin Enderby2014-07-319-68/+110
| | | | | | | | | | | | | This allows assembling the two new instructions, encls and enclu for the SKX processor model. Note the diffs are a bigger than what might think, but to fit the new MRM_CF and MRM_D7 in things in the right places things had to be renumbered and shuffled down causing a bit more diffs. rdar://16228228 llvm-svn: 214460
* X86 MC: Don't crash on empty memory operand parensReid Kleckner2014-07-311-2/+4
| | | | | | | | Instead, create an absolute memory operand. Fixes PR20504. llvm-svn: 214457
OpenPOWER on IntegriCloud