summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG
Commit message (Collapse)AuthorAgeFilesLines
...
* Add missing check to SETCC optimization.Eli Friedman2013-09-241-0/+1
| | | | | | PR17338. llvm-svn: 191337
* DAGCombiner: Unify rotate matching for extended and unextended amounts.Benjamin Kramer2013-09-241-79/+57
| | | | | | No functionality change, lots of indentation changes. llvm-svn: 191303
* Initial support for Neon scalar instructions.Jiangning Liu2013-09-241-1/+2
| | | | | | | | | | Patch by Ana Pazos. 1.Added support for v1ix and v1fx types. 2.Added Scalar Pairwise Reduce instructions. 3.Added initial implementation of Scalar Arithmetic instructions. llvm-svn: 191263
* [stackprotector] Allow for copies from vreg -> vreg to be in a terminator ↵Michael Gottesman2013-09-241-6/+26
| | | | | | | | | | | sequence. Sometimes a copy from a vreg -> vreg sneaks into the middle of a terminator sequence. It is safe to slice this into the stack protector success bb. This fixes PR16979. llvm-svn: 191260
* fix typo: than -> thenKay Tiong Khoo2013-09-231-1/+1
| | | | llvm-svn: 191214
* ISelDAG: spot chain cycles involving MachineNodesTim Northover2013-09-221-5/+5
| | | | | | | | | | | | | | | | | Previously, the DAGISel function WalkChainUsers was spotting that it had entered already-selected territory by whether a node was a MachineNode (amongst other things). Since it's fairly common practice to insert MachineNodes during ISelLowering, this was not the correct check. Looking around, it seems that other nodes get their NodeId set to -1 upon selection, so this makes sure the same thing happens to all MachineNodes and uses that characteristic to determine whether we should stop looking for a loop during selection. This should fix PR15840. llvm-svn: 191165
* Revert "SelectionDAG: Teach the legalizer to split SETCC if VSELECT needs ↵Juergen Ributzka2013-09-212-35/+8
| | | | | | | | splitting too." This reverts commit r191130. llvm-svn: 191138
* SelectionDAG: Teach the legalizer to split SETCC if VSELECT needs splitting too.Juergen Ributzka2013-09-212-8/+35
| | | | | | | | | | | | | | | | | | The Type Legalizer recognizes that VSELECT needs to be split, because the type is to wide for the given target. The same does not always apply to SETCC, because less space is required to encode the result of a comparison. As a result VSELECT is split and SETCC is unrolled into scalar comparisons. This commit fixes the issue by checking for VSELECT-SETCC patterns in the DAG Combiner. If a matching pattern is found, then the result mask of SETCC is promoted to the expected vector mask for the given target. This mask has usually te same size as the VSELECT return type (except for Intel KNL). Now the type legalizer will split both VSELECT and SETCC. This allows the following X86 DAG Combine code to sucessfully detect the MIN/MAX pattern. This fixes PR16695, PR17002, and <rdar://problem/14594431>. llvm-svn: 191130
* Add braces to suppress Clang's dangling-else warning.David Blaikie2013-09-201-2/+4
| | | | | | These violations were introduced in r191049 llvm-svn: 191059
* PR16726: extend rol/ror matchingKai Nacke2013-09-191-2/+37
| | | | | | | | | | | | | | | | | | | | | C-like languages promote types like unsigned short to unsigned int before performing an arithmetic operation. Currently the rotate matcher in the DAGCombiner does not consider this situation. This commit extends the DAGCombiner in the way that the pattern (or (shl ([az]ext x), (*ext y)), (srl ([az]ext x), (*ext (sub 32, y)))) is folded into ([az]ext (rotl x, y)) The matching is restricted to aext and zext because in this cases the upper bits are either undefined or known. Test case is included. This fixes PR16726. llvm-svn: 191049
* Revert PR16726: extend rol/ror matchingKai Nacke2013-09-191-35/+0
| | | | | | There is a buildbot failure. Need to investigate this. llvm-svn: 191048
* PR16726: extend rol/ror matchingKai Nacke2013-09-191-0/+35
| | | | | | | | | | | | | | | | | | | | | C-like languages promote types like unsigned short to unsigned int before performing an arithmetic operation. Currently the rotate matcher in the DAGCombiner does not consider this situation. This commit extends the DAGCombiner in the way that the pattern (or (shl ([az]ext x), (*ext y)), (srl ([az]ext x), (*ext (sub 32, y)))) is folded into ([az]ext (rotl x, y)) The matching is restricted to aext and zext because in this cases the upper bits are either undefined or known. Test case is included. This fixes PR16726. llvm-svn: 191045
* DAGCombiner: Don't fold vector muls with constants that look like a splat of ↵Benjamin Kramer2013-09-191-3/+7
| | | | | | | | a power of 2 but differ in bit width. PR17283. llvm-svn: 191000
* Debug info: Get rid of the VLA indirection hack in FastISel.Adrian Prantl2013-09-181-15/+10
| | | | | | | | Use the DIVariable::isIndirect() flag set by the frontend instead of guessing whether to set the machine location's indirection bit. Paired commit with CFE. llvm-svn: 190961
* Added documentation to getMemsetStores.Serge Pavlov2013-09-171-0/+18
| | | | llvm-svn: 190866
* [SelectionDAG] Teach the vector scalarizer about TRUNCATE.Quentin Colombet2013-09-172-3/+4
| | | | | | | | | | | When a truncate node defines a legal vector type but uses an illegal vector type, the legalization process was splitting the vector until <1 x vector> type, but then it was failing to scalarize the node because it did not know how to handle TRUNCATE. <rdar://problem/14989896> llvm-svn: 190830
* Debug info: Fix PR16736 and rdar://problem/14990587.Adrian Prantl2013-09-162-1/+2
| | | | | | | A DBG_VALUE is register-indirect iff the first operand is a register _and_ the second operand is an immediate. llvm-svn: 190821
* Prevent assert in CombinerGlobalAA with null valuesHal Finkel2013-09-151-1/+1
| | | | | | | DAGCombiner::isAlias can be called with SrcValue1 or SrcValue2 null, and we can't use AA in this case (if we try, then the casting code in AA will assert). llvm-svn: 190763
* Remove pointless assertion after r190376Matt Arsenault2013-09-121-2/+0
| | | | llvm-svn: 190565
* Revert "Give internal classes hidden visibility."Benjamin Kramer2013-09-114-4/+4
| | | | | | | It works with clang, but GCC has different rules so we can't make all of those hidden. This reverts commit r190534. llvm-svn: 190536
* Give internal classes hidden visibility.Benjamin Kramer2013-09-114-4/+4
| | | | | | Worth 100k on a linux/x86_64 Release+Asserts clang. llvm-svn: 190534
* Rename variables for consistency.Eli Friedman2013-09-111-6/+6
| | | | | | No functional change. llvm-svn: 190466
* Fix unused variables.Eli Friedman2013-09-101-1/+0
| | | | llvm-svn: 190448
* Don't use getSetCCResultType for creating a vselectMatt Arsenault2013-09-101-2/+1
| | | | | | | | | | | | | | | | | | | The vselect mask isn't a setcc. This breaks in the case when the result of getSetCCResultType is larger than the vector operands e.g. %tmp = select i1 %cmp <2 x i8> %a, <2 x i8> %b when getSetCCResultType returns <2 x i32>, the assertion that the (MaskTy.getSizeInBits() == Op1.getValueType().getSizeInBits()) is hit. No test since I don't think I can hit this with any of the current targets. The R600/SI implementation would break, since it returns a vector of i1 for this, but it doesn't reach ExpandSELECT for other reasons. llvm-svn: 190376
* white spaces and long linesJack Carter2013-09-091-45/+81
| | | | llvm-svn: 190358
* Revert patches to add case-range support for PR1255.Bob Wilson2013-09-092-36/+53
| | | | | | | | | | | | | | | | | The work on this project was left in an unfinished and inconsistent state. Hopefully someone will eventually get a chance to implement this feature, but in the meantime, it is better to put things back the way the were. I have left support in the bitcode reader to handle the case-range bitcode format, so that we do not lose bitcode compatibility with the llvm 3.3 release. This reverts the following commits: 155464, 156374, 156377, 156613, 156704, 156757, 156804 156808, 156985, 157046, 157112, 157183, 157315, 157384, 157575, 157576, 157586, 157612, 157810, 157814, 157815, 157880, 157881, 157882, 157884, 157887, 157901, 158979, 157987, 157989, 158986, 158997, 159076, 159101, 159100, 159200, 159201, 159207, 159527, 159532, 159540, 159583, 159618, 159658, 159659, 159660, 159661, 159703, 159704, 160076, 167356, 172025, 186736 llvm-svn: 190328
* SelectionDAG: create correct BooleanContent constantsTim Northover2013-09-062-2/+11
| | | | | | | | | | | | | | | Occasionally DAGCombiner can spot that a SETCC operation is completely redundant and reduce it to "all true" or "all false". If this happens to a vector, the value produced has to take account of what a normal comparison would have produced, which may be an all-1s bitmask. The fix in SelectionDAG.cpp is tested, however, as far as I can see the code in TargetLowering.cpp is possibly unreachable and almost certainly irrelevant when triggered so there are no tests. However, I believe it's still clearly the right change and may save someone else some hassle if it suddenly becomes reachable. So I'm doing it anyway. llvm-svn: 190147
* Use TargetSubtargetInfo::useAA() in DAGCombineHal Finkel2013-08-291-3/+10
| | | | | | | This uses the TargetSubtargetInfo::useAA() function to control the defaults of the -combiner-alias-analysis and -combiner-global-alias-analysis options. llvm-svn: 189564
* Fix a typo and coding style of a previous commit. No functional change.Juergen Ributzka2013-08-281-3/+2
| | | | llvm-svn: 189526
* DAGCombiner: make sure or/shl/srl really has zero high bits before forming bswapTim Northover2013-08-271-6/+24
| | | | | | | | We want to convert code like (or (srl N, 8), (shl N, 8)) into (srl (bswap N), const), but this is only valid if the bits above 16 on the source pattern are 0, the checks we were doing on this were slightly wrong before. llvm-svn: 189348
* Remove an over-zealous assertion. A pointer type could be illegal if the ↵Owen Anderson2013-08-271-1/+0
| | | | | | target is prepared to custom-legalize pointer operands. This assertion was evaluated before the target would have a chance to do so, making it impossible. llvm-svn: 189299
* SelectionDAG: Remove unnecessary uses of TargetLowering::getPointerTy()Tom Stellard2013-08-267-43/+50
| | | | | | | | | | | | If we have a binary operation like ISD:ADD, we can set the result type equal to the result type of one of its operands rather than using TargetLowering::getPointerTy(). Also, any use of DAG.getIntPtrConstant(C) as an operand for a binary operation can be replaced with: DAG.getConstant(C, OtherOperand.getValueType()); llvm-svn: 189227
* SelectionDAG: Use correct pointer size when splitting vector storesTom Stellard2013-08-261-1/+1
| | | | llvm-svn: 189224
* SelectionDAG: Use correct pointer size when lowering function arguments v2Tom Stellard2013-08-261-5/+8
| | | | | | | | | | | | | | | | This adds minimal support to the SelectionDAG for handling address spaces with different pointer sizes. The SelectionDAG should now correctly lower pointer function arguments to the correct size as well as generate the correct code when lowering getelementptr. This patch also updates the R600 DataLayout to use 32-bit pointers for the local address space. v2: - Add more helper functions to TargetLoweringBase - Use CHECK-LABEL for tests llvm-svn: 189221
* Add a function object to compare the first or second component of a std::pair.Benjamin Kramer2013-08-241-10/+1
| | | | | | Replace instances of this scattered around the code base. llvm-svn: 189169
* [stack protector] Work around an issue with the BMOVPCB_CALL instruction on ↵Michael Gottesman2013-08-221-1/+1
| | | | | | | | | | ARM by disabling does not return on __stack_chk_fail. This is to fix the bots while I look to see if there is something I can do here. rdar://14811848 llvm-svn: 189076
* [stackprotector] When finding the split point to splice off the end of a ↵Michael Gottesman2013-08-221-9/+44
| | | | | | | | parentmbb into a successmbb, include any DBG_VALUE MI. Fix for PR16954. llvm-svn: 188987
* SelectionDAG: Make sure stores are always added to the LegalizedNodes listTom Stellard2013-08-211-1/+1
| | | | | | | | | | | | | | | | When truncated vector stores were being custom lowered in VectorLegalizer::LegalizeOp(), the old (illegal) and new (legal) node pair was not being added to LegalizedNodes list. Instead of the legalized result being passed to VectorLegalizer::TranslateLegalizeResult(), the result was being passed back into VectorLegalizer::LegalizeOp(), which ended up adding a (new, new) pair to the list instead. This was causing an assertion failure when a custom lowered truncated vector store was the last instruction a basic block and the VectorLegalizer was unable to find it in the LegalizedNodes list when updating the DAG root. llvm-svn: 188953
* Teach BaseIndexOffset::match to identify base pointers in loops.Juergen Ributzka2013-08-211-2/+14
| | | | | | | | | | | | | | The small utility function that pattern matches Base + Index + Offset patterns for loads and stores fails to recognize the base pointer for loads/stores from/into an array at offset 0 inside a loop. As a result DAGCombiner::MergeConsecutiveStores was not able to merge all stores. This commit fixes the issue by adding an additional pattern match and also a test case. Reviewer: Nadav llvm-svn: 188936
* [SystemZ] Use SRST to optimize memchrRichard Sandiford2013-08-202-0/+36
| | | | | | | | | | | | | | | | | | | SystemZTargetLowering::emitStringWrapper() previously loaded the character into R0 before the loop and made R0 live on entry. I'd forgotten that allocatable registers weren't allowed to be live across blocks at this stage, and it confused LiveVariables enough to cause a miscompilation of f3 in memchr-02.ll. This patch instead loads R0 in the loop and leaves LICM to hoist it after RA. This is actually what I'd tried originally, but I went for the manual optimisation after noticing that R0 often wasn't being hoisted. This bug forced me to go back and look at why, now fixed as r188774. We should also try to optimize null checks so that they test the CC result of the SRST directly. The select between null and the SRST GPR result could then usually be deleted as dead. llvm-svn: 188779
* Remove unused variables that crept in.Michael Gottesman2013-08-201-6/+0
| | | | llvm-svn: 188761
* Teach selectiondag how to handle the stackprotectorcheck intrinsic.Michael Gottesman2013-08-203-4/+390
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, generation of stack protectors was done exclusively in the pre-SelectionDAG Codegen LLVM IR Pass "Stack Protector". This necessitated splitting basic blocks at the IR level to create the success/failure basic blocks in the tail of the basic block in question. As a result of this, calls that would have qualified for the sibling call optimization were no longer eligible for optimization since said calls were no longer right in the "tail position" (i.e. the immediate predecessor of a ReturnInst instruction). Then it was noticed that since the sibling call optimization causes the callee to reuse the caller's stack, if we could delay the generation of the stack protector check until later in CodeGen after the sibling call decision was made, we get both the tail call optimization and the stack protector check! A few goals in solving this problem were: 1. Preserve the architecture independence of stack protector generation. 2. Preserve the normal IR level stack protector check for platforms like OpenBSD for which we support platform specific stack protector generation. The main problem that guided the present solution is that one can not solve this problem in an architecture independent manner at the IR level only. This is because: 1. The decision on whether or not to perform a sibling call on certain platforms (for instance i386) requires lower level information related to available registers that can not be known at the IR level. 2. Even if the previous point were not true, the decision on whether to perform a tail call is done in LowerCallTo in SelectionDAG which occurs after the Stack Protector Pass. As a result, one would need to put the relevant callinst into the stack protector check success basic block (where the return inst is placed) and then move it back later at SelectionDAG/MI time before the stack protector check if the tail call optimization failed. The MI level option was nixed immediately since it would require platform specific pattern matching. The SelectionDAG level option was nixed because SelectionDAG only processes one IR level basic block at a time implying one could not create a DAG Combine to move the callinst. To get around this problem a few things were realized: 1. While one can not handle multiple IR level basic blocks at the SelectionDAG Level, one can generate multiple machine basic blocks for one IR level basic block. This is how we handle bit tests and switches. 2. At the MI level, tail calls are represented via a special return MIInst called "tcreturn". Thus if we know the basic block in which we wish to insert the stack protector check, we get the correct behavior by always inserting the stack protector check right before the return statement. This is a "magical transformation" since no matter where the stack protector check intrinsic is, we always insert the stack protector check code at the end of the BB. Given the aforementioned constraints, the following solution was devised: 1. On platforms that do not support SelectionDAG stack protector check generation, allow for the normal IR level stack protector check generation to continue. 2. On platforms that do support SelectionDAG stack protector check generation: a. Use the IR level stack protector pass to decide if a stack protector is required/which BB we insert the stack protector check in by reusing the logic already therein. If we wish to generate a stack protector check in a basic block, we place a special IR intrinsic called llvm.stackprotectorcheck right before the BB's returninst or if there is a callinst that could potentially be sibling call optimized, before the call inst. b. Then when a BB with said intrinsic is processed, we codegen the BB normally via SelectBasicBlock. In said process, when we visit the stack protector check, we do not actually emit anything into the BB. Instead, we just initialize the stack protector descriptor class (which involves stashing information/creating the success mbbb and the failure mbb if we have not created one for this function yet) and export the guard variable that we are going to compare. c. After we finish selecting the basic block, in FinishBasicBlock if the StackProtectorDescriptor attached to the SelectionDAGBuilder is initialized, we first find a splice point in the parent basic block before the terminator and then splice the terminator of said basic block into the success basic block. Then we code-gen a new tail for the parent basic block consisting of the two loads, the comparison, and finally two branches to the success/failure basic blocks. We conclude by code-gening the failure basic block if we have not code-gened it already (all stack protector checks we generate in the same function, use the same failure basic block). llvm-svn: 188755
* Add a llvm.copysign intrinsicHal Finkel2013-08-193-0/+9
| | | | | | | | | | | | | | | | | | | | | This adds a llvm.copysign intrinsic; We already have Libfunc recognition for copysign (which is turned into the FCOPYSIGN SDAG node). In order to autovectorize calls to copysign in the loop vectorizer, we need a corresponding intrinsic as well. In addition to the expected changes to the language reference, the loop vectorizer, BasicTTI, and the SDAG builder (the intrinsic is transformed into an FCOPYSIGN node, just like the function call), this also adds FCOPYSIGN to a few lists in LegalizeVector{Ops,Types} so that vector copysigns can be expanded. In TargetLoweringBase::initActions, I've made the default action for FCOPYSIGN be Expand for vector types. This seems correct for all in-tree targets, and I think is the right thing to do because, previously, there was no way to generate vector-values FCOPYSIGN nodes (and most targets don't specify an action for vector-typed FCOPYSIGN). llvm-svn: 188728
* Improve the widening of integral binary vector operationsPaul Redmond2013-08-192-10/+24
| | | | | | | | | | | | | | - split WidenVecRes_Binary into WidenVecRes_Binary and WidenVecRes_BinaryCanTrap - WidenVecRes_BinaryCanTrap preserves the original behaviour for operations that can trap - WidenVecRes_Binary simply widens the operation and improves codegen for 3-element vectors by allowing widening and promotion on x86 (matches the behaviour of unary and ternary operation widening) - use WidenVecRes_Binary for operations on integers. Reviewed by: nrotem llvm-svn: 188699
* Add ExpandFloatOp_FCOPYSIGN to handle ppcf128-related expansionsHal Finkel2013-08-192-0/+13
| | | | | | | | | | We had previously been asserting when faced with a FCOPYSIGN f64, ppcf128 node because there was no way to expand the FCOPYSIGN node. Because ppcf128 is the sum of two doubles, and the first double must have the larger magnitude, we can take the sign from the first double. As a result, in addition to fixing the crash, this is also an optimization. llvm-svn: 188655
* ARM: Fix more fast-isel verifier failures.Jim Grosbach2013-08-161-0/+4
| | | | | | | | | | | | | Teach the generic instruction selection helper functions to constrain the register classes of their input operands. For non-physical register references, the generic code needs to be careful not to mess that up when replacing references to result registers. As the comment indicates for MachineRegisterInfo::replaceRegWith(), it's important to call constrainRegClass() first. rdar://12594152 llvm-svn: 188593
* [SystemZ] Use SRST to implement strlen and strnlenRichard Sandiford2013-08-162-0/+63
| | | | | | It would also make sense to use it for memchr; I'm working on that now. llvm-svn: 188547
* [SystemZ] Use MVST to implement strcpy and stpcpyRichard Sandiford2013-08-162-0/+38
| | | | llvm-svn: 188546
* [SystemZ] Use CLST to implement strcmpRichard Sandiford2013-08-162-0/+34
| | | | llvm-svn: 188544
* [SystemZ] Fix handling of 64-bit memcmp resultsRichard Sandiford2013-08-162-19/+31
| | | | | | | | | | | | | Generalize r188163 to cope with return types other than MVT::i32, just as the existing visitMemCmpCall code did. I've split this out into a subroutine so that it can be used for other upcoming patches. I also noticed that I'd used the wrong API to record the out chain. It's a load that uses DAG.getRoot() rather than getRoot(), so the out chain should go on PendingLoads. I don't have a testcase for that because we don't do any interesting scheduling on z yet. llvm-svn: 188540
OpenPOWER on IntegriCloud