summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* [NFC] Fix whitespace.Chad Rosier2016-01-111-1/+1
| | | | llvm-svn: 257365
* LegalizeDAG: Expand ctlz with ctlz_zero_undef if legalMatt Arsenault2016-01-111-2/+12
| | | | llvm-svn: 257345
* [BranchFolding] Set correct mem refs (2nd try)Junmo Park2016-01-111-1/+1
| | | | | | | | | | | | This is a recommit of r257253 which was reverted in r257270. Previous testcase can make failure on some targets due to using opt with O3 option. Original Summary: Merge MBBICommon and MBBI's MMOs. Differential Revision: http://reviews.llvm.org/D15990 llvm-svn: 257317
* Speed up LiveDebugValuesDaniel Berlin2016-01-101-28/+52
| | | | | | | | | | | | | | | | Summary: Use proper dataflow ordering to speed convergence. This will converge the testcase on bug 26055 in 2 iterations. (data structures speedups to come to make even that faster) Reviewers: kcc, samsonov, echristo, dblaikie, tvvikram Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16039 llvm-svn: 257292
* Don't use random class variables across functionsDaniel Berlin2016-01-101-29/+30
| | | | llvm-svn: 257271
* Revert "[BranchFolding] Set correct mem refs"Michael Zolotukhin2016-01-091-1/+1
| | | | | | This reverts commit 1ff11017d2669b933b29fcbb6451cfcda34ad693. llvm-svn: 257270
* [BranchFolding] Set correct mem refsJunmo Park2016-01-091-1/+1
| | | | | | | | Merge MBBICommon and MBBI's MMOs. Differential Revision: http://reviews.llvm.org/D15990 llvm-svn: 257253
* [DAGCombiner] don't dereference an operand that doesn't exist (PR26070)Sanjay Patel2016-01-081-12/+13
| | | | | | | | | | | | | The bug was introduced with changes for x86-64 fp128: http://reviews.llvm.org/rL254653 I don't know why an x86 change is here, so I'll follow up in: http://reviews.llvm.org/D15134 Should fix: https://llvm.org/bugs/show_bug.cgi?id=26070 llvm-svn: 257200
* Test commit access - add a blank line in comment.Tim Shen2016-01-081-0/+1
| | | | llvm-svn: 257192
* Do not ASSERTZEXT for i16 result of bitcast from f16 operandPirama Arumuga Nainar2016-01-081-6/+2
| | | | | | | | | | | | | | | | | | | | | | | Summary: During legalization if i16, do not ASSERTZEXT the result of FP_TO_FP16. Directly return an FP_TO_FP16 node with return type as the promote-to-type of i16. This patch also removes extraneous length check. This legalization should be valid even if integer and float types are of different lengths. This patch breaks a hard-float test for fp16 args. The test is changed to allow a vmov to zero-out the top bits, and also ensure that the return value is in an FP register. Reviewers: ab, jmolloy Subscribers: srhines, llvm-commits Differential Revision: http://reviews.llvm.org/D15438 llvm-svn: 257184
* [WinEH] CatchHandler which don't have catch objects in StackColoringDavid Majnemer2016-01-081-1/+3
| | | | | | | | | | | | | | | | | StackColoring rewrites the frame indicies of operations involving allocas if it can find that the life time of two objects do not overlap. MSVC EH needs to be kept aware of this if happens in the event that a catch object has moved around. However, we represent the non-existance of a catch object with a sentinel frame index (INT_MAX). This sentinel also happens to be the EmptyKey of the SlotRemap DenseMap. Testing for whether or not we need to translate the frame index fails in this case because we call the count method on the DenseMap with the EmptyKey, leading to assertions. Instead, check if it is our sentinel value before trying to look into the DenseMap. This fixes PR26073. llvm-svn: 257182
* [WinEH] Update WinEHFuncInfo if StackColoring merges allocasDavid Majnemer2016-01-082-3/+11
| | | | | | | | | | | | | | | Windows EH keeping track of which frame index corresponds to a catchpad in order to inform the runtime where the catch parameter should be initialized. LLVM's optimizations are able to prove that the memory used by the catch parameter can be reused with another memory optimization, changing it's frame index. We need to keep WinEHFuncInfo up to date with respect to this or we will miscompile/assert. This fixes PR26069. llvm-svn: 257158
* Remove extra whitespace. NFC.Junmo Park2016-01-081-8/+8
| | | | llvm-svn: 257144
* LiveInterval: A LiveRange is enough for ConnectedVNInfoEqClasses::Classify()Matthias Braun2016-01-083-7/+7
| | | | llvm-svn: 257129
* [LiveDebugValues] Replace several lines of code with operator[].Alexey Samsonov2016-01-071-16/+2
| | | | llvm-svn: 257114
* Temporarily revert r257105 "[Verifier] Check that debug values have proper size"Keno Fischer2016-01-071-14/+2
| | | | | | | Looks like there's a case where clang generates debug info that triggers the new verifier check. Reverting while investigating. llvm-svn: 257107
* [Verifier] Check that debug values have proper sizeKeno Fischer2016-01-071-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Teach the Verifier to make sure that the storage size given to llvm.dbg.declare or the value size given to llvm.dbg.value agree with what is declared in DebugInfo. This is implicitly assumed in a number of passes (e.g. in SROA). Additionally this catches a number of common mistakes, such as passing a pointer when a value was intended or vice versa. One complication comes from stack coloring which modifies the original IR when it merges allocas in order to make sure that if AA falls back to the IR it gets the correct result. However, given this new invariant, indiscriminately replacing one alloca by a different (differently sized one) is no longer valid. Fix this by just undefing out any use of the alloca in a dbg.declare in this case. Additionally, I had to fix a number of test cases. Of particular note: - I regenerated dbg-changes-codegen-branch-folding.ll from the given source as it was affected by the bug fixed in r256077 - two-cus-from-same-file.ll was changed to avoid having a variable-typed debug variable as that would depend on the target, even though this test is supposed to be generic - I had to manually declared size/align for reference type. See also the discussion for D14275/r253186. - fpstack-debuginstr-kill.ll required changing `double` to `long double` - most others were just a question of adding OP_deref Reviewers: aprantl Differential Revision: http://reviews.llvm.org/D14276 llvm-svn: 257105
* Turn off lldb debug tuning by default for FreeBSDDimitry Andric2016-01-071-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: In rL242338, debugger tuning was introduced, and the tuning for FreeBSD was set to lldb by default. However, for the foreseeable future we still need to default to gdb tuning, since lldb is not ready for all of FreeBSD's architectures, and some system tools (like objcopy, etc) have not yet been adapted to cope with the lldb tuned format, which has .apple sections. Therefore, let FreeBSD use gdb by default for now. Reviewers: emaste, probinson Subscribers: llvm-commits, emaste Differential Revision: http://reviews.llvm.org/D15966 llvm-svn: 257103
* Added support for macro emission in dwarf (supporting DWARF version 4).Amjad Aboud2016-01-073-4/+123
| | | | | | Differential Revision: http://reviews.llvm.org/D15495 llvm-svn: 257060
* Remove extra whitespace. NFC.Junmo Park2016-01-071-1/+1
| | | | llvm-svn: 257047
* Undo spurious change made in r256965David Majnemer2016-01-071-2/+1
| | | | llvm-svn: 257028
* [Statepoints] Add test cases around vectors and stablize testPhilip Reames2016-01-071-1/+3
| | | | | | | | | | Unlike my comment in 257022 said, it turns out we do handle constant vectors in the statepoint lowering, but only because SelectionDAG doesn't actually produce constants for them. Add a couple of tests which show this working. Also, add a triple to the same test file to hopefully fix a failing bot. It turns out we do han llvm-svn: 257025
* [Statepoints] Initial support for relocating vectors of pointersPhilip Reames2016-01-071-7/+7
| | | | | | | | | | | | Currently, we try to split vectors of pointers back into their component pointer elements during rewrite-statepoints-for-gc. This is less than ideal since presumably the vectorizer chose to vectorize for a reason. :) It's also been a source of bugs - in particular, the relocation logic as currently implemented was recently discovered to be wrong. The alternate approach is to allow gc.relocates of vector-of-pointer type and update the backend to handle them. That's what this patch tries to do. This won't actually enable vector-of-pointers in practice - there are some RS4GC changes needed - but the lowering is standalone and testable so it makes sense to separate. Note that there are some known cases around vector constants which this patch does not handle. Once this is in, I'll send another patch with individual fixes and test cases. Differential Revision: http://reviews.llvm.org/D15632 llvm-svn: 257022
* [ShrinkWrapping] Give up on irreducible CFGs.Quentin Colombet2016-01-071-0/+47
| | | | | | | | | | | We need to know whether or not a given basic block is in a loop for the analysis to be correct. Loop information may be incomplete on irreducible CFGs, therefore we may generate incorrect code if we use it in those situations. This fixes PR25988. llvm-svn: 257012
* rangify; NFCISanjay Patel2016-01-061-56/+31
| | | | llvm-svn: 256998
* Recommit r256952 "Filtering IR printing for print-after-all/print-before-all"Weiming Zhao2016-01-061-1/+3
| | | | | | | | Fix lit test fail due to outputting an extra line. Differential Revision: http://reviews.llvm.org/D15776 llvm-svn: 256987
* Consolidate MemRefs handling from BranchFolding and correct latent bugPhilip Reames2016-01-062-18/+35
| | | | | | | | | | | | Move the logic from BranchFolding to use the shared infrastructure for merging MMOs introduced in 256909. This has the effect of making BranchFolding more capable. In the process, fix a latent bug. The existing handling for merging didn't handle the case where one of the instructions being merged had overflowed and dropped MemRefs. This was a latent bug in the places the code was commoned from, but potentially reachable in BranchFolding. Once this is in, we're left with a single place to consider implementing MMO unique-ing as proposed in http://reviews.llvm.org/D15230. Differential Revision: http://reviews.llvm.org/D15913 llvm-svn: 256966
* [WinEH] Remove calculateCatchReturnSuccessorColorsDavid Majnemer2016-01-063-23/+9
| | | | | | | | | | | | | | The functionality that calculateCatchReturnSuccessorColors provides was once non-trivial: it was a computation layered on top of funclet coloring. These days, LLVM IR directly encodes what calculateCatchReturnSuccessorColors computed, obsoleting the need for it. No functionality change is intended. llvm-svn: 256965
* [ShrinkWrap] Fix FindIDom to only have one kind of failure.Michael Kuperstein2016-01-061-6/+4
| | | | | | | | | | | | | FindIDom() can fail in two different ways - it can either return nullptr or the block itself, depending on the circumstances. Some users of FindIDom() check one error condition, while others check the other. Change it to always return nullptr on failure. This fixes PR26004. Differential Revision: http://reviews.llvm.org/D15847 llvm-svn: 256955
* Revert r256952 due to lit test fails.Weiming Zhao2016-01-061-3/+1
| | | | llvm-svn: 256954
* Filtering IR printing for print-after-all/print-before-allWeiming Zhao2016-01-061-1/+3
| | | | | | | | | | | | | | | Summary: This patch implements "-print-funcs" option to support function filtering for IR printing like -print-after-all, -print-before etc. Examples: -print-after-all -print-funcs=foo,bar Reviewers: mcrosier, joker.eph Subscribers: tejohnson, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D15776 llvm-svn: 256952
* ScheduleDAGInstrs: Bug fix for missed memory dependency.Geoff Berry2016-01-061-3/+12
| | | | | | | | | | | | | | | | | | | | Summary: In buildSchedGraph(), when adding memory dependencies for loads, move the call to adjustChainDeps() after the call to addChainDependency(AliasChain) to handle the case where addChainDependency(AliasChain) ends up not adding a dependency and instead putting the SU on the RejectMemNodes list. The call to adjustChainDeps() must be done after the call to addChainDependency() in order to process the SU added to the RejectMemNodes list to create memory dependencies for it. Reviewers: hfinkel, atrick, jonpa, resistor Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D15927 llvm-svn: 256950
* Fix a warning [NFC]Philip Reames2016-01-061-1/+2
| | | | llvm-svn: 256916
* 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
OpenPOWER on IntegriCloud