summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Add a debug option to dump PBQP graphs during register allocation.Lang Hames2012-03-261-0/+29
| | | | llvm-svn: 153483
* SCEV fix: Handle loop invariant loads.Andrew Trick2012-03-261-1/+5
| | | | | | Fixes PR11882: NULL dereference in ComputeLoadConstantCompareExitLimit. llvm-svn: 153480
* Use the file in the inlined die rather than the compile unit forEric Christopher2012-03-261-1/+2
| | | | | | | | | | | | | | backtrace locations. Testcase forthcoming, but I wanted to get some testing here. Should fix: PR12323 PR12314 rdar://11091100 llvm-svn: 153471
* 153465 was incorrect. In this code we wanted to check that the pointer ↵Nadav Rotem2012-03-261-4/+3
| | | | | | operand is of pointer type (and not vector type). llvm-svn: 153468
* Made RuntimeDyldMachO support vanilla i386Sean Callanan2012-03-262-0/+44
| | | | | | | | | relocations. The algorithm is the same as that for x86_64. Scattered relocations, a feature present in i386 but not on x86_64, are not yet supported. llvm-svn: 153466
* PR12357: The pointer was used before it was checked.Nadav Rotem2012-03-261-1/+3
| | | | llvm-svn: 153465
* LSR ivchain bug fix: corner case with ConstantExpr.Andrew Trick2012-03-261-2/+3
| | | | | | Fixes PR11950. llvm-svn: 153463
* comment typoAndrew Trick2012-03-261-1/+1
| | | | llvm-svn: 153462
* eliminate an unneeded branch, part of PR12357Chris Lattner2012-03-261-7/+2
| | | | llvm-svn: 153458
* Tidy.Eric Christopher2012-03-261-1/+1
| | | | llvm-svn: 153456
* Tidy.Eric Christopher2012-03-261-6/+9
| | | | llvm-svn: 153455
* Revert r153423 as this is causing failures on our internal nightly testers.Chad Rosier2012-03-262-41/+0
| | | | | | | | Original commit message: Use the new range metadata in computeMaskedBits and add a new optimization to instruction simplify that lets us remove an and when loading a boolean value. llvm-svn: 153452
* LSR cleanup: potential bug caught by PVS-Studio.Andrew Trick2012-03-261-2/+3
| | | | | | Thanks Andrey. llvm-svn: 153451
* [tsan] treat vtable pointer updates in a special way (requires tbaa); fix a ↵Kostya Serebryany2012-03-261-0/+25
| | | | | | bug (forgot to return true after instrumenting); make sure the tsan tests are run llvm-svn: 153448
* No need to do an expensive stable sort for a bunch of integers.Benjamin Kramer2012-03-261-3/+3
| | | | llvm-svn: 153438
* Add missing include of <new>Douglas Gregor2012-03-261-0/+1
| | | | llvm-svn: 153436
* Fix GetMainExecutable on kFreeBSD.Anton Korobeynikov2012-03-261-3/+3
| | | | | | Patch by Sylvestre Ledru! llvm-svn: 153435
* Prune some includes and forward declarations.Craig Topper2012-03-2613-25/+23
| | | | llvm-svn: 153429
* Add a debug statement.Eric Christopher2012-03-261-1/+3
| | | | llvm-svn: 153428
* Use the new range metadata in computeMaskedBits and add a new optimization toRafael Espindola2012-03-262-0/+41
| | | | | | instruction simplify that lets us remove an and when loding a boolean value. llvm-svn: 153423
* Prune includes and replace uses of ARMRegisterInfo.h with ARMBaeRegisterInfo.hCraig Topper2012-03-267-10/+2
| | | | llvm-svn: 153422
* Replace uses of ARMBaseInstrInfo and ARMTargetMachine with the Base versions.Craig Topper2012-03-258-18/+12
| | | | llvm-svn: 153421
* Teach instsimplify how to simplify comparisons of pointers which areChandler Carruth2012-03-251-1/+45
| | | | | | | constant-offsets of a common base using the generic GEP-walking logic I added for computing pointer differences in the same situation. llvm-svn: 153419
* Switch the pointer-difference simplification logic to only work withChandler Carruth2012-03-251-1/+1
| | | | | | | | | | | | inbounds GEPs. This isn't really necessary for simplifying pointer differences, but I'm planning to re-use the same code to simplify pointer comparisons where it is necessary. Since real code almost exclusively uses inbounds GEPs, it doesn't seem worth it to support the extra complexity of turning it on and off. If anyone would like that back, feel free to shout. Note that instcombine will still catch any of these patterns. llvm-svn: 153418
* Prune some includes and forward declarations.Craig Topper2012-03-253-0/+3
| | | | llvm-svn: 153415
* Teach the function cloner (and thus the inliner) to simplify PHINodesChandler Carruth2012-03-251-12/+18
| | | | | | | | | | | | | | | | | | | | aggressively. There are lots of dire warnings about this being expensive that seem to predate switching to the TrackingVH-based value remapper that is automatically updated on RAUW. This makes it easy to not just prune single-entry PHIs, but to fully simplify PHIs, and to recursively simplify the newly inlined code to propagate PHINode simplifications. This introduces a bit of a thorny problem though. We may end up simplifying a branch condition to a constant when we fold PHINodes, and we would like to nuke any dead blocks resulting from this so that time isn't wasted continually analyzing them, but this isn't easy. Deleting basic blocks *after* they are fully cloned and mapped into the new function currently requires manually updating the value map. The last piece of the simplification-during-inlining puzzle will require either switching to WeakVH mappings or some other piece of refactoring. I've left a FIXME in the testcase about this. llvm-svn: 153410
* Move the instruction simplification of callsite arguments in the inlinerChandler Carruth2012-03-252-89/+34
| | | | | | | | | | | | | | | | | | | | | | | to instead rely on much more generic and powerful instruction simplification in the function cloner (and thus inliner). This teaches the pruning function cloner to use instsimplify rather than just the constant folder to fold values during cloning. This can simplify a large number of things that constant folding alone cannot begin to touch. For example, it will realize that 'or' and 'and' instructions with certain constant operands actually become constants regardless of what their other operand is. It also can thread back through the caller to perform simplifications that are only possible by looking up a few levels. In particular, GEPs and pointer testing tend to fold much more heavily with this change. This should (in some cases) have a positive impact on compile times with optimizations on because the inliner itself will simply avoid cloning a great deal of code. It already attempted to prune proven-dead code, but now it will be use the stronger simplifications to prove more code dead. llvm-svn: 153403
* Add an asserting ValueHandle to the block simplification code which willChandler Carruth2012-03-251-0/+9
| | | | | | | | | | | | | | | | fire if anything ever invalidates the assumption of a terminator instruction being unchanged throughout the routine. I've convinced myself that the current definition of simplification precludes such a transformation, so I think getting some asserts coverage that we don't violate this agreement is sufficient to make this code safe for the foreseeable future. Comments to the contrary or other suggestions are of course welcome. =] The bots are now happy with this code though, so it appears the bug here has indeed been fixed. llvm-svn: 153401
* Don't form a WeakVH around the sentinel node in the instructions BBChandler Carruth2012-03-241-4/+2
| | | | | | | | | | | | | | | | | | | list. This is a bad idea. ;] I'm hopeful this is the bug that's showing up with the MSVC bots, but we'll see. It is definitely unnecessary. InstSimplify won't do anything to a terminator instruction, we don't need to even include it in the iteration range. We can also skip the now dead terminator check, although I've made it an assert to help document that this is an important invariant. I'm still a bit queasy about this because there is an implicit assumption that the terminator instruction cannot be RAUW'ed by the simplification code. While that appears to be true at the moment, I see no guarantee that would ensure it remains true in the future. I'm looking at the cleanest way to solve that... llvm-svn: 153399
* Try to harden the recursive simplification still further. This is againChandler Carruth2012-03-241-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | spotted by inspection, and I've crafted no test case that triggers it on my machine, but some of the windows builders are hitting what looks like memory corruption, so *something* is amiss here. This patch takes a more generalized approach to eliminating double-visits. Imagine code such as: %x = ... %y = add %x, 1 %z = add %x, %y You can imagine that if we simplify %x, we would add %y and %z to the list. If the use-chain order happens to cause us to add them in reverse order, we could pull %y off first, and simplify it, adding %z to the list. We now have %z on the list twice, and will reference it after it is deleted. Currently, all my test cases happen to not trigger this, likely due to the use-chain ordering, but there seems no guarantee that such a situation could not occur, so we should handle it correctly. Again, if anyone knows how to craft a testcase that actually triggers this, please let me know. llvm-svn: 153397
* Don't add the instruction about to be RAUW'ed and erased to theChandler Carruth2012-03-241-2/+4
| | | | | | | | | worklist. This can happen in theory when an instruction uses itself, such as a PHI node. This was spotted by inspection, and unfortunately I've not been able to come up with a test case that would trigger it. If anyone has ideas, let me know... llvm-svn: 153396
* Fix null to integer conversion warnings.Jean-Daniel Dupas2012-03-241-2/+2
| | | | llvm-svn: 153395
* Refactor the interface to recursively simplifying instructions to be tadChandler Carruth2012-03-243-63/+79
| | | | | | | | | | | | | | | | | | | | | | | | | bit simpler by handling a common case explicitly. Also, refactor the implementation to use a worklist based walk of the recursive users, rather than trying to use value handles to detect and recover from RAUWs during the recursive descent. This fixes a very subtle bug in the previous implementation where degenerate control flow structures could cause mutually recursive instructions (PHI nodes) to collapse in just such a way that From became equal to To after some amount of recursion. At that point, we hit the inf-loop that the assert at the top attempted to guard against. This problem is defined away when not using value handles in this manner. There are lots of comments claiming that the WeakVH will protect against just this sort of error, but they're not accurate about the actual implementation of WeakVHs, which do still track RAUWs. I don't have any test case for the bug this fixes because it requires running the recursive simplification on unreachable phi nodes. I've no way to either run this or easily write an input that triggers it. It was found when using instruction simplification inside the inliner when running over the nightly test-suite. llvm-svn: 153393
* Remove always true variable.Rafael Espindola2012-03-241-19/+10
| | | | llvm-svn: 153392
* Fix small-integer VAARG on SVR4 ABI PPC64.Hal Finkel2012-03-241-5/+17
| | | | | | | The PPC64 SVR4 ABI requires integer stack arguments, and thus the var. args., that are smaller than 64 bits be zero extended to 64 bits. llvm-svn: 153373
* Add the ability to promote legal integer VAARGs. This is required for the ↵Hal Finkel2012-03-241-1/+33
| | | | | | PPC64 SVR4 ABI. llvm-svn: 153372
* Fix the MSVC build.Francois Pichet2012-03-241-2/+2
| | | | llvm-svn: 153366
* PTX: Fix predicate logic bugJustin Holewinski2012-03-242-21/+36
| | | | | | | | | | | | | | | | | | | | | | Code such as: %vreg100 = setcc %vreg10, -1, SETNE brcond %vreg10, %tgt was being incorrectly morphed into %vreg100 = and %vreg10, 1 brcond %vreg10, %tgt where the 'and' instruction could be eliminated since such logic is on 1-bit types in the PTX back-end, leaving us with just: brcond %vreg10, %tgt which essentially gives us inverted branch conditions. llvm-svn: 153364
* More IndVarSimplify cleanup.Andrew Trick2012-03-241-25/+16
| | | | llvm-svn: 153362
* First part of PR12251. Add documentation and verifier support for the rangeRafael Espindola2012-03-242-0/+29
| | | | | | metadata. llvm-svn: 153359
* add EP_OptimizerLast extension pointKostya Serebryany2012-03-231-0/+1
| | | | llvm-svn: 153353
* It's possible for two types, which are isomorphic, to be added to theBill Wendling2012-03-231-6/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | destination module, but one of them isn't used in the destination module. If another module comes along and the uses the unused type, there could be type conflicts when the modules are finally linked together. (This happened when building LLVM.) The test that was reduced is: Module A: %Z = type { %A } %A = type { %B.1, [7 x x86_fp80] } %B.1 = type { %C } %C = type { i8* } declare void @func_x(%C*, i64, i64) declare void @func_z(%Z* nocapture) Module B: %B = type { %C.1 } %C.1 = type { i8* } %A.2 = type { %B.3, [5 x x86_fp80] } %B.3 = type { %C.1 } define void @func_z() { %x = alloca %A.2, align 16 %y = getelementptr inbounds %A.2* %x, i64 0, i32 0, i32 0 call void @func_x(%C.1* %y, i64 37, i64 927) nounwind ret void } declare void @func_x(%C.1*, i64, i64) declare void @func_y(%B* nocapture) (Unfortunately, this test doesn't fail under llvm-link, only during an LTO linking.) The '%C' and '%C.1' clash. The destination module gets the '%C' declaration. When merging Module B, it looks at the '%C.1' subtype of the '%B' structure. It adds that in, because that's cool. And when '%B.3' is processed, it uses the '%C.1'. But the '%B' has used '%C' and we prefer to use '%C'. So the '@func_x' type is changed to 'void (%C*, i64, i64)', but the type of '%x' in '@func_z' remains '%A.2'. The GEP resolves to a '%C.1', which conflicts with the '@func_x' signature. We can resolve this situation by making sure that the type is used in the destination before saying that it should be used in the module being merged in. With this fix, LLVM and Clang both compile under LTO. <rdar://problem/10913281> llvm-svn: 153351
* ARM tidy up ARMConstantIsland.cpp.Jim Grosbach2012-03-231-156/+158
| | | | | | No functional change, just tidy up the code and nomenclature a bit. llvm-svn: 153347
* Pretty-printing comments for literal floating point in .s files.Jim Grosbach2012-03-231-2/+6
| | | | | | | Dump the hex representation to the comment stream as well as the float value. llvm-svn: 153346
* Add a hook in MCELFObjectTargetWriter to allow targets to sort relocationAkira Hatanaka2012-03-232-29/+13
| | | | | | entries in the relocation table before they are written out to the file. llvm-svn: 153345
* Don't convert objc_retainAutoreleasedReturnValue to objc_retain if itDan Gohman2012-03-231-2/+11
| | | | | | is retaining the return value of an invoke that it immediately follows. llvm-svn: 153344
* It's not possible to insert code immediately after an invoke in theDan Gohman2012-03-231-32/+42
| | | | | | | | | | | | same basic block, and it's not safe to insert code in the successor blocks if the edges are critical edges. Splitting those edges is possible, but undesirable, especially on the unwind side. Instead, make the bottom-up code motion to consider invokes to be part of their successor blocks, rather than part of their parent blocks, so that it doesn't push code past them and onto the edges. This fixes PR12307. llvm-svn: 153343
* Make it feasible for clients using EngineBuilder to capture the ↵Owen Anderson2012-03-232-38/+42
| | | | | | | | TargetMachine that is created as part of selecting the appropriate target. This is necessary if the client wants to be able to mutate TargetOptions (for example, fast FP math mode) after the initial creation of the ExecutionEngine. llvm-svn: 153342
* Add support for register masks to PBQP.Lang Hames2012-03-231-4/+38
| | | | llvm-svn: 153341
* Include cstdio in a few place that depended on getting it transitively ↵Benjamin Kramer2012-03-232-1/+3
| | | | | | through StringExtras.h llvm-svn: 153328
OpenPOWER on IntegriCloud