summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Reverting r215966, r215965, r215964, r215963, r215960, r215959, r215958, and ↵Aaron Ballman2014-08-194-387/+482
| | | | | | r215957 (these commits all rely on previous commits) due to build breakage. These commits cause failed assertions when testing Clang using MSVC 2013. The asserts are triggered from the std::equal call within ArrayRef::equals due to being passed invalid input (ArrayRef.begin() is returning a nullptr which is problematic). llvm-svn: 215981
* [mips] Add assembler support for .set arch=x directive.Toma Tabacu2014-08-193-0/+48
| | | | | | | | | | | | | | | | | | Summary: This directive is similar to ".set mipsX". It is used to change the CPU target of the assembler, enabling it to accept instructions for a specific CPU. This patch only implements the r4000 CPU (which is treated internally as generic mips3) and the generic ISAs. Contains work done by Matheus Almeida. Reviewers: dsanders Reviewed By: dsanders Differential Revision: http://reviews.llvm.org/D4884 llvm-svn: 215978
* InstCombine: ((A & ~B) ^ (~A & B)) to A ^ BMayur Pandey2014-08-191-0/+10
| | | | | | | | | | | | | Proof using CVC3 follows: $ cat t.cvc A, B : BITVECTOR(32); QUERY BVXOR((A & ~B),(~A & B)) = BVXOR(A,B); $ cvc3 t.cvc Valid. Differential Revision: http://reviews.llvm.org/D4898 llvm-svn: 215974
* Const-correct and prevent a copy of a SmallPtrSet.Craig Topper2014-08-191-2/+2
| | | | llvm-svn: 215973
* test commit (spelling correction)Mayur Pandey2014-08-191-1/+1
| | | | llvm-svn: 215970
* Make it explicit that ExecutionEngine takes ownership of the modules.Rafael Espindola2014-08-198-75/+80
| | | | llvm-svn: 215967
* IR: Reduce RAUW traffic in ConstantVectorDuncan P. N. Exon Smith2014-08-191-3/+27
| | | | | | | | | Avoid creating a new `ConstantVector` on an RAUW of one of its members. This reduces RAUW traffic on any containing constant. This is part of PR20515. llvm-svn: 215966
* IR: Fix ConstantArray::replaceUsesOfWithOnConstant()Duncan P. N. Exon Smith2014-08-191-0/+6
| | | | | | | | Previously, `ConstantArray::replaceUsesOfWithOnConstant()` neglected to check whether it becomes a `ConstantDataArray`. Call `ConstantArray::getImpl()` to check for that. llvm-svn: 215965
* IR: Factor out replaceUsesOfWithOnConstantImpl(), NFCDuncan P. N. Exon Smith2014-08-191-94/+80
| | | | | | | Factor out common code, and take advantage of the new function to add early returns to the callers. llvm-svn: 215964
* IR: Split up Constant{Array,Vector}::get(), NFCDuncan P. N. Exon Smith2014-08-191-4/+13
| | | | | | | | Introduce `getImpl()` that tries the simplification logic from `get()` and then gives up. This allows the logic to be reused elsewhere in a follow-up commit. llvm-svn: 215963
* [X86, X87 stackifier] Do not mark an operand of a debug instruction as kill.Akira Hatanaka2014-08-191-0/+3
| | | | | | <rdar://problem/16952634> llvm-svn: 215962
* IR: Reduce RAUW traffic in ConstantExprDuncan P. N. Exon Smith2014-08-191-0/+44
| | | | | | | | | | | | | Avoid RAUW-ing `ConstantExpr` when an operand changes unless the new `ConstantExpr` already has users. This prevents the RAUW from rippling up the expression tree unnecessarily. This commit indirectly adds test coverage for r215953 (this is how I came across the bug). This is part of PR20515. llvm-svn: 215960
* IR: Replace uses of ConstantAggrUniqueMap with ConstantUniqueMapDuncan P. N. Exon Smith2014-08-192-164/+49
| | | | | | | Now that `ConstantAggrUniqueMap` and `ConstantUniqueMap` work the same way, change the aggregates to use the new one. llvm-svn: 215959
* Remove extraneous typenames from r215957Duncan P. N. Exon Smith2014-08-191-2/+2
| | | | llvm-svn: 215958
* IR: Rewrite ConstantUniqueMapDuncan P. N. Exon Smith2014-08-194-267/+218
| | | | | | | | | | | | | | | | | | | | | Rewrite `ConstantUniqueMap` to be more similar to `ConstantAggrUniqueMap`. - Use a `DenseMap` with custom MapInfo instead of a `std::map` with linear lookups and deletion. - Don't waste memory explicitly storing (heavyweight) keys. Only `ConstantExpr` and `InlineAsm` actually use this data structure, so I also updated them to use it. This code cleanup is a precursor to reducing RAUW traffic on `ConstantExpr` -- I felt badly adding a new (linear) call to `ConstantUniqueMap::FindExistingKey`, so this designs away the concern. A follow-up commit will transition the users of `ConstantAggrUniqueMap` over. llvm-svn: 215957
* IR: Declare LookupKey right before its use, NFCDuncan P. N. Exon Smith2014-08-191-6/+4
| | | | llvm-svn: 215956
* IR: ArrayRef-ize {Insert,Extract}ValueConstantExpr constructorsDuncan P. N. Exon Smith2014-08-191-8/+6
| | | | | | No functionality change. llvm-svn: 215955
* Prevent clang-format from moving the namespace closing brace, NFCDuncan P. N. Exon Smith2014-08-191-1/+1
| | | | llvm-svn: 215954
* NVPTX: Use RAUW instead of reinventing the wheelDuncan P. N. Exon Smith2014-08-191-6/+9
| | | | | | | | | | | | | | | | This code had a homemade RAUW that was incorrect when a user was a constant: instead of calling `replaceUsersWithOnConstant()` it would incorrectly update the operand in-place, invalidating `LLVMContextImpl::ExprConstants`. RAUW does the job better. The ValueHandle that `GVMap` is holding onto needs to be removed first, so this commit also removes each variable from the map on-the-fly. Since deletions from `ExprConstants` use a linear search that compares directly on the pointer value (instead of using the key), there isn't an obvious way to expose this with a testcase. llvm-svn: 215953
* LLParser: Handle BlockAddresses on-the-flyDuncan P. N. Exon Smith2014-08-192-93/+126
| | | | | | | | | | | | | | | | | | | | | | | | Previously all `blockaddress()` constants were treated as forward references. They were resolved twice: once at the end of the function in question, and again at the end of the module. Furthermore, if the same blockaddress was referenced N times, the parser created N distinct `GlobalVariable`s (one for each reference). Instead, resolve all block addresses at the beginning of the function, creating the standard `BasicBlock` forward references used for all other basic block references. After the function, all references can be resolved immediately. To check for the condition of parsing block addresses from within the same function, I created a reference to the current per-function-state in `BlockAddressPFS`. Also, create only one forward-reference per basic block. Because forward references to block addresses are rare, the data structure here shouldn't matter. If somehow it does someday, this can be pretty easily changed to a `DenseMap<std::pair<ValID, ValID>, GV>`. This is part of PR20515. llvm-svn: 215952
* Use a range loop. NFC.Rafael Espindola2014-08-181-2/+2
| | | | llvm-svn: 215948
* These classes only need a StringRef, not a MemoryBuffer.Rafael Espindola2014-08-184-8/+8
| | | | llvm-svn: 215945
* Delete unused method.Rafael Espindola2014-08-182-6/+0
| | | | llvm-svn: 215944
* Answer to Philip Reames commentsRobin Morisset2014-08-181-6/+27
| | | | | | | | | | - add check for volatile (probably unneeded, but I agree that we should be conservative about it). - strengthen condition from isUnordered() to isSimple(), as I don't understand well enough Unordered semantics (and it also matches the comment better this way) to be confident in the previous behaviour (thanks for catching that one, I had missed the case Monotonic/Unordered). - separate a condition in two. - lengthen comment about aliasing and loads - add tests in GVN/atomic.ll llvm-svn: 215943
* Weak relaxing of the constraints on atomics in MemoryDependencyAnalysisRobin Morisset2014-08-181-4/+22
| | | | | | | Monotonic accesses do not have to kill the analysis, as long as the QueryInstr is not itself atomic. llvm-svn: 215942
* [MCJIT] Respect target endianness in RuntimeDyldMachO and RuntimeDyldChecker.Lang Hames2014-08-183-6/+22
| | | | | | This patch may address some of the issues described in http://llvm.org/PR20640. llvm-svn: 215938
* Make llvm-objdump handle both arm and thumb disassembly from the same Mach-OKevin Enderby2014-08-181-1/+84
| | | | | | | | | | file with -macho, the Mach-O specific object file parser option. After some discussion I chose to do this implementation contained in the logic of llvm-objdump’s MachODump.cpp using a second disassembler for thumb when needed and with updates mostly contained in the MachOObjectFile class. llvm-svn: 215931
* [X86][Haswell][SchedModel] Tidy up.Quentin Colombet2014-08-181-56/+63
| | | | | | <rdar://problem/15607571> llvm-svn: 215924
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+30
| | | | | | | | | Group: Floating Point XMM and YMM instructions. Sub-group: Other instructions. <rdar://problem/15607571> llvm-svn: 215923
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+9
| | | | | | | | | Group: Floating Point XMM and YMM instructions. Sub-group: Logic instructions. <rdar://problem/15607571> llvm-svn: 215922
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+68
| | | | | | | | | Group: Floating Point XMM and YMM instructions. Sub-group: Math instructions. <rdar://problem/15607571> llvm-svn: 215921
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+170
| | | | | | | | | Group: Floating Point XMM and YMM instructions. Sub-group: Arithmetic instructions. <rdar://problem/15607571> llvm-svn: 215920
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+170
| | | | | | | | | Group: Floating Point XMM and YMM instructions. Sub-group: Conversion instructions. <rdar://problem/15607571> llvm-svn: 215919
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+144
| | | | | | | | | Group: Floating Point XMM and YMM instructions. Sub-group: Move instructions. <rdar://problem/15607571> llvm-svn: 215918
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+9
| | | | | | | | | Group: Integer MMX and XMM instructions. Sub-group: Other instructions. <rdar://problem/15607571> llvm-svn: 215917
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+31
| | | | | | | | | Group: Integer MMX and XMM instructions. Sub-group: Logic instructions. <rdar://problem/15607571> llvm-svn: 215916
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+63
| | | | | | | | | Group: Integer MMX and XMM instructions. Sub-group: Arithmetic instructions. <rdar://problem/15607571> llvm-svn: 215915
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+251
| | | | | | | | | Group: Integer MMX and XMM instructions. Sub-group: Move instructions. <rdar://problem/15607571> llvm-svn: 215914
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+16
| | | | | | | | | Group: Floating Point x87 instructions. Sub-group: Math instructions. <rdar://problem/15607571> llvm-svn: 215913
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+70
| | | | | | | | | Group: Floating Point x87 instructions. Sub-group: Arithmetic instructions. <rdar://problem/15607571> llvm-svn: 215912
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+126
| | | | | | | | | Group: Floating Point x87 instructions. Sub-group: Move instructions. <rdar://problem/15607571> llvm-svn: 215911
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+37
| | | | | | | | | Group: Integer instructions. Sub-group: Other instructions. <rdar://problem/15607571> llvm-svn: 215910
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+26
| | | | | | | | | Group: Integer instructions. Sub-group: Synchronization instructions. <rdar://problem/15607571> llvm-svn: 215909
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+42
| | | | | | | | | Group: Integer instructions. Sub-group: String instructions. <rdar://problem/15607571> llvm-svn: 215908
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+60
| | | | | | | | | Group: Integer instructions. Sub-group: Control transfer instructions. <rdar://problem/15607571> llvm-svn: 215907
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+216
| | | | | | | | | Group: Integer instructions. Sub-group: Logic instructions. <rdar://problem/15607571> llvm-svn: 215906
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+192
| | | | | | | | | Group: Integer instructions. Sub-group: Arithmetic instructions. <rdar://problem/15607571> llvm-svn: 215905
* [X86][Haswell][SchedModel] Add architecture specific scheduling models.Quentin Colombet2014-08-181-0/+145
| | | | | | | | | Group: Integer instructions. Sub-group: Move instructions. <rdar://problem/15607571> llvm-svn: 215904
* Make use of isAtLeastRelease/Acquire in the ARM/AArch64 backendsRobin Morisset2014-08-184-15/+10
| | | | | | | | | | | | | | | | | Summary: Make use of isAtLeastRelease/Acquire in the ARM/AArch64 backends These helper functions are introduced in D4844. Depends D4844 Test Plan: make check-all passes Reviewers: jfb Subscribers: aemerson, llvm-commits, mcrosier, reames Differential Revision: http://reviews.llvm.org/D4937 llvm-svn: 215902
* Teach the AArch64 backend to handle f16Oliver Stannard2014-08-182-0/+12
| | | | | | | This allows the AArch64 backend to handle fadd, fsub, fmul and fdiv operations on f16 (half-precision) types by promoting to f32. llvm-svn: 215891
OpenPOWER on IntegriCloud