summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix bug in LowerConstantPool. Akira Hatanaka2012-03-271-1/+1
| | | | llvm-svn: 153498
* Add T9 to the list of live-in registers of the entry basic block. Akira Hatanaka2012-03-271-0/+2
| | | | llvm-svn: 153497
* Retrieve and add the offset of a symbol in applyFixup rather than retrieve andAkira Hatanaka2012-03-272-67/+67
| | | | | | | set it in MipsMCCodeEmitter::getMachineOpValue. Assert in getMachineOpValue if MachineOperand MO is of an unexpected type. llvm-svn: 153494
* Define function MipsGetSymAndOffset which returns a fixup's symbol and theAkira Hatanaka2012-03-271-0/+30
| | | | | | offset applied to it. llvm-svn: 153493
* Post-ra LICM should take care not to hoist an instruction that would clobber aEvan Cheng2012-03-271-4/+28
| | | | | | | | register that's read by the preheader terminator. rdar://11095580 llvm-svn: 153492
* Rewrite computation of Value in adjustFixupValue so that the upper 48-bits areAkira Hatanaka2012-03-271-1/+1
| | | | | | cleared. No functionality change. llvm-svn: 153491
* During MachineCopyPropagation a register may be the source operand of multipleLang Hames2012-03-271-17/+26
| | | | | | | | | | copies being considered for removal. Make sure to track all of the copies, rather than just the most recent encountered, by holding a DenseSet instead of an unsigned in SrcMap. No test case - couldn't reduce something with a sane size. llvm-svn: 153487
* Reserve hardware registers.Akira Hatanaka2012-03-271-0/+4
| | | | llvm-svn: 153486
* ARM has a peephole optimization which looks for a def / use pair. The defEvan Cheng2012-03-261-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | produces a 32-bit immediate which is consumed by the use. It tries to fold the immediate by breaking it into two parts and fold them into the immmediate fields of two uses. e.g movw r2, #40885 movt r3, #46540 add r0, r0, r3 => add.w r0, r0, #3019898880 add.w r0, r0, #30146560 ; However, this transformation is incorrect if the user produces a flag. e.g. movw r2, #40885 movt r3, #46540 adds r0, r0, r3 => add.w r0, r0, #3019898880 adds.w r0, r0, #30146560 Note the adds.w may not set the carry flag even if the original sequence would. rdar://11116189 llvm-svn: 153484
* 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
OpenPOWER on IntegriCloud