summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* Extract helper function to merge MemoryOperand lists [NFC]Philip Reames2016-01-061-0/+20
| | | | | | | | | | In the discussion on http://reviews.llvm.org/D15730, Andy pointed out we had a utility function for merging MMO lists. Since it turned we actually had two copies and there's another review in progress (http://reviews.llvm.org/D15230) which needs the same, extract it into a utility function and clean up the interfaces to make it easier to use with a MachineInstBuilder. I introduced a pair here to track size and allocation together. I think we should probably move in the direction of the MachineOperandsRef helper class, but I'm leaving that for further work. I want to get the poison state introduced before I make major changes to the interface. Differential Revision: http://reviews.llvm.org/D15757 llvm-svn: 256909
* rangify; NFCISanjay Patel2016-01-061-24/+14
| | | | llvm-svn: 256891
* [SelectionDAGBuilder] Set NoUnsignedWrap for inbounds gep and load/store ↵Dan Gohman2016-01-062-9/+52
| | | | | | | | | | | | | | | | | | | | offsets. In an inbounds getelementptr, when an index produces a constant non-negative offset to add to the base, the add can be assumed to not have unsigned overflow. This relies on the assumption that addresses can't occupy more than half the address space, which isn't possible in C because it wouldn't be possible to represent the difference between the start of the object and one-past-the-end in a ptrdiff_t. Setting the NoUnsignedWrap flag is theoretically useful in general, and is specifically useful to the WebAssembly backend, since it permits stronger constant offset folding. Differential Revision: http://reviews.llvm.org/D15544 llvm-svn: 256890
* use std::max ; NFCISanjay Patel2016-01-061-3/+2
| | | | llvm-svn: 256889
* [MISched] Explanatory error message when machine model is not complete. NFCMinSeong Kim2016-01-051-1/+1
| | | | | | | | | When not all instructions have a scheduling class, the error message now provides a possible solution. Differential Revision: http://reviews.llvm.org/D15854 llvm-svn: 256839
* [Statepoints] Refactor GCRelocateOperands into an intrinsic wrapper. NFC.Manuel Jacob2016-01-054-50/+40
| | | | | | | | | | | | | | | Summary: This commit renames GCRelocateOperands to GCRelocateInst and makes it an intrinsic wrapper, similar to e.g. MemCpyInst. Also, all users of GCRelocateOperands were changed to use the new intrinsic wrapper instead. Reviewers: sanjoy, reames Subscribers: reames, sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D15762 llvm-svn: 256811
* MachineInstrBundle: Fix reversed isSuperRegisterEq() callMatthias Braun2016-01-051-1/+1
| | | | | | | | | | | | | | | Unfortunately this fix had the effect of exposing the -verify-machineinstrs FIXME of X86InstrInfo.cpp in two testcases for which I disabled it for now. Two testcases also have additional pushq/popq where the corrected code cannot prove that %rax is dead any longer. Looking at the examples, this could potentially be fixed by improving computeRegisterLiveness() to check the live-in lists of the successors blocks when reaching the end of a block. This fixes http://llvm.org/PR25951. llvm-svn: 256799
* Clarify that the bypassSlowDivision optimization operates on a single BB [v2]Eric Christopher2016-01-041-2/+8
| | | | | | | | | | | | | | | | Update some comments to be more explicit. Change bypassSlowDivision and the functions it calls so that they take BasicBlock*s and Instruction*s, rather than Function::iterator&s and BasicBlock::iterator&s. Change the APIs so that the caller is responsible for updating the iterator, rather than the callee. This makes control flow much easier to follow. Patch by Justin Lebar! llvm-svn: 256789
* [WinEH] Update CoreCLR EH state numberingJoseph Tremoulet2016-01-042-82/+203
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fix the CLR state numbering to generate correct tables, and update the lit test to verify them. The CLR numbering assigns one state number to each catchpad and cleanuppad. It also computes two tree-like relations over states: 1) Each state has a "HandlerParentState", which is the state of the next outer handler enclosing this state's handler (same as nearest ancestor per the ParentPad linkage on EH pads, but skipping over catchswitches). 2) Each state has a "TryParentState", which: a) for a catchpad that's not the last handler on its catchswitch, is the state of the next catchpad on that catchswitch. b) for all other pads, is the state of the pad whose try region is the next outer try region enclosing this state's try region. The "try regions are not present as such in the IR, but will be inferred based on the placement of invokes and pads which reach each other by exceptional exits. Catchswitches do not get their own states, but each gets mapped to the state of its first catchpad. Table generation requires each state's "unwind dest" state to have a lower state number than the given state. Since HandlerParentState can be computed as a function of a pad's ParentPad, and TryParentState can be computed as a function of its unwind dest and the TryParentStates of its children, the CLR state numbering algorithm first computes HandlerParentState in a top-down pass, then computes TryParentState in a bottom-up pass. Also reword some comments/names in the CLR EH table generation to make the distinction between the different kinds of "parent" clear. Reviewers: rnk, andrew.w.kaylor, majnemer Subscribers: AndyAyers, llvm-commits Differential Revision: http://reviews.llvm.org/D15325 llvm-svn: 256760
* [X86] Make hasFP constant timeDavid Majnemer2016-01-041-0/+3
| | | | | | | | | | We need a frame pointer if there is a push/pop sequence after the prologue in order to unwind the stack. Scanning the instructions to figure out if this happened made hasFP not constant-time which is a violation of expectations. Let's compute this up-front and reuse that computation when we need it. llvm-svn: 256730
* [SelectionDAG] Pulled out common code for CONCAT_VECTORS node creationSimon Pilgrim2016-01-031-39/+55
| | | | | | Pulled out the similar CONCAT_VECTORS creation code from the 2/3 operand getNode() calls (to handle all UNDEF and all BUILD_VECTOR cases). Added a similar handler to the general getNode() call as well. llvm-svn: 256709
* WinEHPrepare.cpp: Suppress a warning for -Asserts. [-Wunused-variable]NAKAMURA Takumi2016-01-031-4/+2
| | | | llvm-svn: 256694
* [WinEH] Update catchrets with cloned successorsJoseph Tremoulet2016-01-021-4/+38
| | | | | | | | | | | | | | | | | | | | Summary: Add a pass to update catchrets when their successors get cloned; the existing pass doesn't catch these because it walks the funclet whose blocks are being cloned but the catchret is in a child funclet. Also update the test for removing incoming PHI values; when the predecessor is a catchret, the relevant color is the catchret's parentPad, not its block's color. Reviewers: andrew.w.kaylor, rnk, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15840 llvm-svn: 256689
* Correct misleading formatting of several ifs followed by two statements ↵Yaron Keren2016-01-021-5/+16
| | | | | | | | | | without braces. While the original code would work with or without braces, it makes sense to set HaveSemi to true only if (!HaveSemi), otherwise it's already true, so I put the assignment inside the if block. This addresses PR25998. llvm-svn: 256688
* [WinEH] Add additional verificationDavid Majnemer2016-01-021-4/+7
| | | | | | | | Recolor the IR to make sure our computed colors are not hiding any bugs. Also, verifyFunction if we are running some post-preparation operations; some of these operations can hide latent bugs. llvm-svn: 256687
* don't repeat function names in comments; NFCSanjay Patel2015-12-291-57/+47
| | | | llvm-svn: 256584
* use auto with dyn_casted values; NFCSanjay Patel2015-12-291-6/+3
| | | | llvm-svn: 256581
* use auto with dyn_casted values; NFCSanjay Patel2015-12-291-11/+9
| | | | llvm-svn: 256579
* fix formatting; NFCSanjay Patel2015-12-291-11/+10
| | | | llvm-svn: 256574
* use range-based for-loop; NFCISanjay Patel2015-12-291-8/+6
| | | | llvm-svn: 256572
* Add command line options to force function/loop alignments.Chad Rosier2015-12-292-0/+18
| | | | | | | These are being added for testing purposes. http://reviews.llvm.org/D15648 llvm-svn: 256571
* don't repeat function names in comments; NFCSanjay Patel2015-12-291-14/+13
| | | | llvm-svn: 256569
* use range-based for-loops; NFCISanjay Patel2015-12-291-9/+6
| | | | llvm-svn: 256566
* [ptr-traits] Sink a constructor definition to the .cpp file and addChandler Carruth2015-12-291-0/+4
| | | | | | | | | | | | missing includes so that the pointee types for DenseMap pointer keys and such are complete prior to us querying the pointer traits for them. This is part of a series of patches to allow LLVM to check for complete pointee types when computing its pointer traits. This is absolutely necessary to get correct (or reproducible) results for things like how many low bits are guaranteed to be zero. llvm-svn: 256550
* [X86] Better support for the MCU psABI (LLVM part)Michael Kuperstein2015-12-282-4/+8
| | | | | | | | | | | | | | | | This adds support for the MCU psABI in a way different from r251223 and r251224, basically reverting most of these two patches. The problem with the approach taken in r251223/4 is that it only handled libcalls that originated from the backend. However, the mid-end also inserts quite a few libcalls and assumes these use the platform's default calling convention. The previous patch tried to insert inregs when necessary both in the FE and, somewhat hackily, in the CG. Instead, we now define a new default calling convention for the MCU, which doesn't use inreg marking at all, similarly to what x86-64 does. Differential Revision: http://reviews.llvm.org/D15054 llvm-svn: 256494
* [SelectionDAG] Teach LegalizeVectorOps to not unroll CTLZ_ZERO_UNDEF and ↵Craig Topper2015-12-271-0/+14
| | | | | | CTTZ_ZERO_UNDEF if the non-ZERO_UNDEF form is legal or custom. Will be used to simplify X86 code in a follow on commit. llvm-svn: 256476
* [WinEH] Add comments explaining the EH tablesDavid Majnemer2015-12-271-31/+114
| | | | | | | This is aids in debugging WinEH, similar functionality is present for DWARF EH. llvm-svn: 256455
* [CodeGen] Use generic printAsOperand machinery instead of hand rolling itDavid Majnemer2015-12-251-3/+7
| | | | | | | | We already know how to properly print out basic blocks in printAsOperand, we should not roll it ourselves in AsmPrinter::EmitBasicBlockStart. No functionality change is intended. llvm-svn: 256413
* Use range-based for loops. NFCCraig Topper2015-12-241-40/+32
| | | | llvm-svn: 256363
* [Statepoints] Use Indirect operands for spill slotsPhilip Reames2015-12-232-5/+35
| | | | | | | | | | Teach the statepoint lowering code to emit Indirect stackmap entries for spill inserted by StatepointLowering (i.e. SelectionDAG), but Direct stackmap entries for in-IR allocas which represent manual stack slots. This is what the docs call for (http://llvm.org/docs/StackMaps.html#stack-map-format), but we've been emitting both as Direct. This was pointed out recently on the mailing list as a bug. It also blocks http://reviews.llvm.org/D15632 which extends the lowering to handle vector-of-pointers since only Indirect references can encode a variable sized slot. To implement this, I introduced a new flag on the StackObject class used to maintian information about stack slots. I original considered (and prototyped in http://reviews.llvm.org/D15632), the idea of using the existing isSpillSlot flag, but end up deciding that was a bit too risky and that the cost of adding a new flag was low. Having the new flag will also allow us - in the future - to emit better comments in verbose assembly which indicate where a particular stack spill around a call comes from. (deopt, gc, regalloc). Differential Revision: http://reviews.llvm.org/D15759 llvm-svn: 256352
* [MemOperands] Clarify code around dropping memory operands [NFC]Philip Reames2015-12-231-1/+1
| | | | | | Clarify a comment about what it means to drop memory operands from an instruction. While I'm adding change the name of the method slightly to make it a bit more clear what's going on when reading calling code. llvm-svn: 256346
* [MachineLICM] Fix handling of memoperandsPhilip Reames2015-12-231-2/+12
| | | | | | | | | | As far as I can tell, the correct interpretation of an empty memoperands list is that we didn't have sufficient room to store information about the MachineInstr, NOT that the MachineInstr doesn't access any particular bit of memory. This appears to be fairly consistent in a number of places, but I'm not 100% sure of this interpretation. I'd really appreciate someone more knowledgeable confirming my reading of the code. This patch fixes two latent bugs in MachineLICM - given the above assumption - and adds comments to document the meaning and required handling. I don't have test cases; these were noticed by inspection. Differential Revision: http://reviews.llvm.org/D15730 llvm-svn: 256335
* [WinEH] Don't visit the same catchswitch twiceDavid Majnemer2015-12-231-7/+15
| | | | | | | | | | | | | We visited the same catchswitch twice because it was both the child of another funclet and the predecessor of a cleanuppad. Instead, change the numbering algorithm to only recurse if the unwind destination of the inner funclet agrees with the unwind destination of the catchswitch. This fixes PR25926. llvm-svn: 256317
* [GC] Make GCStrategy::isGCManagedPointer a type predicate not a value ↵Philip Reames2015-12-233-7/+7
| | | | | | | | | | | predicate [NFC] Reasons: 1) The existing form was a form of false generality. None of the implemented GCStrategies use anything other than a type. Its becoming more and more clear we're going to need some type of strong GC pointer in the type system and we shouldn't pretend otherwise at this point. 2) The API was awkward when applied to vectors-of-pointers. The old one could have been made to work, but calling isGCManagedPointer(Ty->getScalarType()) is much cleaner than the Value alternatives. 3) The rewriting implementation effectively assumes the type based predicate as well. We should be consistent. llvm-svn: 256312
* [BPI] Replace weights by probabilities in BPI.Cong Hou2015-12-221-5/+6
| | | | | | | | | | | | This patch removes all weight-related interfaces from BPI and replace them by probability versions. With this patch, we won't use edge weight anymore in either IR or MC passes. Edge probabilitiy is a better representation in terms of CFG update and validation. Differential revision: http://reviews.llvm.org/D15519 llvm-svn: 256263
* Remove deprecated llvm.experimental.gc.result.{int,float,ptr} intrinsics.Manuel Jacob2015-12-221-3/+0
| | | | | | | | | | | | | | Summary: These were deprecated 11 months ago when a generic llvm.experimental.gc.result intrinsic, which works for all types, was added. Reviewers: sanjoy, reames Subscribers: sanjoy, chenli, llvm-commits Differential Revision: http://reviews.llvm.org/D15719 llvm-svn: 256262
* Typo. NFC.Chad Rosier2015-12-221-1/+1
| | | | llvm-svn: 256242
* [ASMPrinter] Fix missing handling of DW_OP_bit_pieceKeno Fischer2015-12-221-0/+3
| | | | | | | | In r256077, I added printing for DIExpressions in DEBUG_VALUE comments, but neglected to handle DW_OP_bit_piece operands. Thanks to Mikael Holmen and Joerg Sonnenberger for spotting this. llvm-svn: 256236
* [MC, COFF] Support link /incremental conditionallyDavid Majnemer2015-12-211-0/+2
| | | | | | | | | | | | | | | | Today, we always take into account the possibility that object files produced by MC may be consumed by an incremental linker. This results in us initialing fields which vary with time (TimeDateStamp) which harms hermetic builds (e.g. verifying a self-host went well) and produces sub-optimal code because we cannot assume anything about the relative position of functions within a section (call sites can get redirected through incremental linker thunks). Let's provide an MCTargetOption which controls this behavior so that we can disable this functionality if we know a-priori that the build will not rely on /incremental. llvm-svn: 256203
* Fix PR24563 (LiveDebugVariables unconditionally propagates all DBG_VALUEs)Adrian Prantl2015-12-211-52/+36
| | | | | | | | | | | | | | | | LiveDebugVariables unconditionally propagates all DBG_VALUE down the dominator tree, which happens to work fine if there already is another DBG_VALUE or the DBG_VALUE happends to describe a single-assignment vreg but is otherwise wrong if the DBG_VALUE is coming from only one of the predecessors. In r255759 we introduced a proper data flow analysis scheduled after LiveDebugVariables that correctly propagates DBG_VALUEs across basic block boundaries. With the new pass in place, the incorrect propagation in LiveDebugVariables can be retired witout loosing any of the benefits where LiveDebugVariables happened to do the right thing. llvm-svn: 256188
* Implemented Support of IA interrupt and exception handlers:Amjad Aboud2015-12-211-0/+5
| | | | | | | | http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html Differential Revision: http://reviews.llvm.org/D15567 llvm-svn: 256155
* Remove unnecessary casts. NFC.Manuel Jacob2015-12-191-6/+5
| | | | llvm-svn: 256101
* SelectionDAG: Cleanup integer bin op promotion functions.Matt Arsenault2015-12-192-34/+17
| | | | | | | SDIV and UDIV had special handling, but this is the same handling that min/max need. llvm-svn: 256098
* Clean up the processing of dbg.value in various placesKeno Fischer2015-12-192-8/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: First up is instcombine, where in the dbg.declare -> dbg.value conversion, the llvm.dbg.value needs to be called on the actual loaded value, rather than the address (since the whole point of this transformation is to be able to get rid of the alloca). Further, now that that's cleaned up, we can remove a hack in the backend, that would add an implicit OP_deref if the argument to dbg.value was an alloca. This stems from before the existence of DIExpression and is no longer necessary since the deref can be expressed explicitly. Now, in order to make sure that the tests pass with this change, we need to correct the printing of DEBUG_VALUE comments to take into account the expression, which wasn't taken into account before. Unfortunately, for both these changes, there were a number of incorrect test cases (mostly the wrong number of DW_OP_derefs, but also a couple where the test itself was broken more badly). aprantl and I have gone through and adjusted these test case in order to make them pass with these fixes and in some cases to make sure they're actually testing what they are meant to test. Reviewers: aprantl Subscribers: dsanders Differential Revision: http://reviews.llvm.org/D14186 llvm-svn: 256077
* Fix broken type legalization of min/maxMatt Arsenault2015-12-192-2/+20
| | | | | | | This was using an anyext when promoting the type when zext/sext is required. llvm-svn: 256074
* Use getEdgeProbability() instead of getEdgeWeight() in BFI and remove ↵Cong Hou2015-12-181-13/+0
| | | | | | | | | | | | | | getEdgeWeight() interfaces from MBPI. This patch removes all getEdgeWeight() interfaces from CodeGen directory. As getEdgeProbability() is a little more expensive than getEdgeWeight(), I will compose a patch soon in which BPI only stores probabilities instead of edge weights so that getEdgeProbability() will have O(1) time. Differential revision: http://reviews.llvm.org/D15489 llvm-svn: 256039
* Fix PR25838.Cong Hou2015-12-171-0/+6
| | | | | | | | | | This is a quick fix to PR25838. The issue comes from the restriction that we cannot normalize probabilities containing both known and unknown ones. A patch that removes this restriction is under the review now: http://reviews.llvm.org/D15548 llvm-svn: 255867
* Fix funciton->function typo.Eric Christopher2015-12-161-1/+1
| | | | llvm-svn: 255841
* CXX_FAST_TLS calling convention: target independent portion.Manman Ren2015-12-161-2/+2
| | | | | | | | | Update supportSplitCSR's interface to take machine function instead of the calling convention. Review comments for http://reviews.llvm.org/D15341 llvm-svn: 255818
* Set debugger tuning from TargetOptions (NFC)Paul Robinson2015-12-162-38/+4
| | | | | | Differential Revision: http://reviews.llvm.org/D15427 llvm-svn: 255810
OpenPOWER on IntegriCloud