summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-6/+9
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* CodeGen: Remove commented out codeJustin Bogner2014-08-021-2/+0
| | | | | | | These two lines have been commented out for over 4 years. They aren't helping anyone. llvm-svn: 214615
* Revert "[C++11] Add predecessors(BasicBlock *) / successors(BasicBlock *) ↵Duncan P. N. Exon Smith2014-07-211-2/+3
| | | | | | | | | iterator ranges." This reverts commit r213474 (and r213475), which causes a miscompile on a stage2 LTO build. I'll reply on the list in a moment. llvm-svn: 213562
* [C++11] Add predecessors(BasicBlock *) / successors(BasicBlock *) iterator ↵Manuel Jacob2014-07-201-3/+2
| | | | | | | | | | | | | | | | | | ranges. Summary: This patch introduces two new iterator ranges and updates existing code to use it. No functional change intended. Test Plan: All tests (make check-all) still pass. Reviewers: dblaikie Reviewed By: dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D4481 llvm-svn: 213474
* Revert "Introduce a string_ostream string builder facilty"Alp Toker2014-06-261-1/+2
| | | | | | Temporarily back out commits r211749, r211752 and r211754. llvm-svn: 211814
* Introduce a string_ostream string builder faciltyAlp Toker2014-06-261-2/+1
| | | | | | | | | | | | | | | | | | | | string_ostream is a safe and efficient string builder that combines opaque stack storage with a built-in ostream interface. small_string_ostream<bytes> additionally permits an explicit stack storage size other than the default 128 bytes to be provided. Beyond that, storage is transferred to the heap. This convenient class can be used in most places an std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair would previously have been used, in order to guarantee consistent access without byte truncation. The patch also converts much of LLVM to use the new facility. These changes include several probable bug fixes for truncated output, a programming error that's no longer possible with the new interface. llvm-svn: 211749
* [FastISel] Collect statistics about failing intrinsic calls.Juergen Ributzka2014-06-101-1/+50
| | | | | | | Add more instruction-specific statistics about failing intrinsic calls during FastISel. llvm-svn: 210556
* Rename ComputeMaskedBits to computeKnownBits. "Masked" has beenJay Foad2014-05-141-2/+2
| | | | | | inappropriate since it lost its Mask parameter in r154011. llvm-svn: 208811
* Pass the value type to TLI::getRegisterByNameHal Finkel2014-05-111-2/+2
| | | | | | | | | | | | | We must validate the value type in TLI::getRegisterByName, because if we don't and the wrong type was used with the IR intrinsic, then we'll assert (because we won't be able to find a valid register class with which to construct the requested copy operation). For PPC64, additionally, the type information is necessary to decide between the 64-bit register and the 32-bit subregister. No functionality change. llvm-svn: 208508
* Implememting named register intrinsicsRenato Golin2014-05-061-0/+30
| | | | | | | | | | | This patch implements the infrastructure to use named register constructs in programs that need access to specific registers (bare metal, kernels, etc). So far, only the stack pointer is supported as a technology preview, but as it is, the intrinsic can already support all non-allocatable registers from any architecture. llvm-svn: 208104
* Convert more loops to range-based equivalentsAlexey Samsonov2014-04-301-9/+5
| | | | llvm-svn: 207714
* Convert SelectionDAGISel::MorphNode to use ArrayRef.Craig Topper2014-04-271-5/+3
| | | | llvm-svn: 207379
* Convert SelectionDAG::MorphNodeTo to use ArrayRef.Craig Topper2014-04-271-1/+2
| | | | llvm-svn: 207378
* Convert SelectionDAG::getNode methods to use ArrayRef<SDValue>.Craig Topper2014-04-261-3/+2
| | | | llvm-svn: 207327
* [Modules] Remove potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-221-1/+2
| | | | | | | | | | | | define below all header includes in the lib/CodeGen/... tree. While the current modules implementation doesn't check for this kind of ODR violation yet, it is likely to grow support for it in the future. It also removes one layer of macro pollution across all the included headers. Other sub-trees will follow. llvm-svn: 206837
* Convert SelectionDAG::getVTList to use ArrayRefCraig Topper2014-04-161-1/+1
| | | | llvm-svn: 206357
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-141-34/+34
| | | | | | instead of comparing to nullptr. llvm-svn: 206142
* Phase 1 of refactoring the MachineRegisterInfo iterators to make them suitableOwen Anderson2014-03-131-3/+4
| | | | | | | | | | | | | | | | | | | for use with C++11 range-based for-loops. The gist of phase 1 is to remove the skipInstruction() and skipBundle() methods from these iterators, instead splitting each iterator into a version that walks operands, a version that walks instructions, and a version that walks bundles. This has the result of making some "clever" loops in lib/CodeGen more verbose, but also makes their iterator invalidation characteristics much more obvious to the casual reader. (Making them concise again in the future is a good motivating case for a pre-incrementing range adapter!) Phase 2 of this undertaking with consist of removing the getOperand() method, and changing operator*() of the operand-walker to return a MachineOperand&. At that point, it should be possible to add range views for them that work as one might expect. llvm-svn: 203757
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-081-1/+1
| | | | | | class. llvm-svn: 203339
* [Layering] Move DebugInfo.h into the IR library where its implementationChandler Carruth2014-03-061-1/+1
| | | | | | already lives. llvm-svn: 203046
* Check for dynamic allocas and inline asm that clobbers sp before buildingHans Wennborg2014-03-051-2/+1
| | | | | | | | | | | | | | | | | | | selection dag (PR19012) In X86SelectionDagInfo::EmitTargetCodeForMemcpy we check with MachineFrameInfo to make sure that ESI isn't used as a base pointer register before we choose to emit rep movs (which clobbers esi). The problem is that MachineFrameInfo wouldn't know about dynamic allocas or inline asm that clobbers the stack pointer until SelectionDAGBuilder has encountered them. This patch fixes the problem by checking for such things when building the FunctionLoweringInfo. Differential Revision: http://llvm-reviews.chandlerc.com/D2954 llvm-svn: 202930
* [C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer2014-03-021-5/+5
| | | | | | Remove the old functions. llvm-svn: 202636
* Add CheckChildInteger to ISelMatcher operations. Removes nearly 2000 bytes ↵Craig Topper2014-02-051-2/+23
| | | | | | from X86 matcher table. llvm-svn: 200821
* [TLI] Add a new hook to TargetLowering to query the target if a load of a ↵Juergen Ributzka2014-01-281-3/+1
| | | | | | | | | | | | | | | | | constant should be converted to simply the constant itself. Before this patch we used getIntImmCost from TargetTransformInfo to determine if a load of a constant should be converted to just a constant, but the threshold for this was set to an arbitrary value. This value works well for the two targets (X86 and ARM) that implement this target-hook, but it isn't target-independent at all. Now targets have the possibility to decide directly if this optimization should be performed. The default value is set to false to preserve the current behavior. The target hook has been moved to TargetLowering, which removed the last use and need of TargetTransformInfo in SelectionDAG. llvm-svn: 200271
* Hide the pre-RA-sched= option.Andrew Trick2014-01-131-1/+1
| | | | | | | | | This is a very confusing option for a feature that will go away. -enable-misched is exposed instead to help triage issues with the new scheduler. llvm-svn: 199133
* Add a machine code print in DEBUG() following instruction selection.Jim Grosbach2013-12-171-0/+3
| | | | | | | Make debugging ISel a bit easier by printing out a dump of the generated code at the end. llvm-svn: 197456
* Reland "Fix miscompile of MS inline assembly with stack realignment"Reid Kleckner2013-12-101-4/+6
| | | | | | | | | | | This re-lands commit r196876, which was reverted in r196879. The tests have been fixed to pass on platforms with a stack alignment larger than 4. Update to clang side tests will land shortly. llvm-svn: 196939
* Revert "Fix miscompile of MS inline assembly with stack realignment"Reid Kleckner2013-12-101-6/+4
| | | | | | | This reverts commit r196876. Its tests failed on the bots, so I'll figure it out tomorrow. llvm-svn: 196879
* Fix miscompile of MS inline assembly with stack realignmentReid Kleckner2013-12-101-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | For stack frames requiring realignment, three pointers may be needed: - ebp to address incoming arguments - esi (could be any callee-saved register) to address locals - esp to address outgoing arguments We would use esi unconditionally without verifying that it did not conflict with inline assembly. This change doesn't do the verification, it simply emits a fatal error on functions that use stack realignment, dynamic SP adjustments, and inline assembly. Because stack realignment is common on Windows, we also no longer assume that MS inline assembly clobbers esp. Instead, we analyze the inline instructions for implicit definitions and check if esp is there. If so, we require the use of a base pointer and consider it in the condition above. Mostly fixes PR16830, but we could try harder to find a non-conflicting base pointer. Reviewers: sunfish Differential Revision: http://llvm-reviews.chandlerc.com/D1317 llvm-svn: 196876
* Fixed tryFoldToZero() for vector types that need expansion.Daniel Sanders2013-11-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: Moved the requirement for SelectionDAG::getConstant() to return legally typed nodes slightly earlier. There were two optional DAGCombine passes that were missed out and were required to produce type-legal DAGs. Simplified a code-path in tryFoldToZero() to use SelectionDAG::getConstant(). This provides support for both promoted and expanded vector types whereas the previous code only supported promoted vector types. Fixes a "Type for zero vector elements is not legal" assertion detected by an llvm-stress generated test. Reviewers: resistor CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2251 llvm-svn: 195635
* Teach ISel not to optimize 'optnone' functions (revised).Paul Robinson2013-11-221-0/+44
| | | | | | | | | | | | | Improvements over r195317: - Set/restore EnableFastISel flag instead of just running FastISel within SelectAllBasicBlocks; the flag is checked in various places, and FastISel won't run properly if those places don't do the right thing. - Test looks for normal ISel versus FastISel behavior, and not something more subtle that doesn't work everywhere. Based on work by Andrea Di Biagio. llvm-svn: 195491
* Revert r195317 (and r195333), "Teach ISel not to optimize 'optnone' functions."NAKAMURA Takumi2013-11-211-40/+1
| | | | | | | | It broke, at least, i686 target. It is reproducible with "llc -mtriple=i686-unknown". FYI, it didn't appear to add either "-O0" or "-fast-isel". llvm-svn: 195339
* Teach ISel not to optimize 'optnone' functions.Paul Robinson2013-11-211-1/+40
| | | | | | Based on work by Andrea Di Biagio. llvm-svn: 195317
* long line correctionJack Carter2013-11-201-1/+2
| | | | llvm-svn: 195179
* [DAG] Refactor vector splitting code in SelectionDAG. No functional change ↵Juergen Ributzka2013-11-191-1/+2
| | | | | | | | intended. Reviewed by Tom llvm-svn: 195156
* Fix illegal DAG produced by SelectionDAG::getConstant() for v2i64 typeDaniel Sanders2013-11-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When getConstant() is called for an expanded vector type, it is split into multiple scalar constants which are then combined using appropriate build_vector and bitcast operations. In addition to the usual big/little endian differences, the case where the element-order of the vector does not have the same endianness as the elements themselves is also accounted for. For example, for v4i32 on big-endian MIPS, the byte-order of the vector is <3210,7654,BA98,FEDC>. For little-endian, it is <0123,4567,89AB,CDEF>. Handling this case turns out to be a nop since getConstant() returns a splatted vector (so reversing the element order doesn't change the value) This fixes a number of cases in MIPS MSA where calling getConstant() during operation legalization introduces illegal types (e.g. to legalize v2i64 UNDEF into a v2i64 BUILD_VECTOR of illegal i64 zeros). It should also handle bigger differences between illegal and legal types such as legalizing v2i64 into v8i16. lowerMSASplatImm() in the MIPS backend no longer needs to avoid calling getConstant() so this function has been updated in the same patch. For the sake of transparency, the steps I've taken since the review are: * Added 'virtual' to isVectorEltOrderLittleEndian() as requested. This revealed that the MIPS tests were falsely passing because a polymorphic function was not actually polymorphic in the reviewed patch. * Fixed the tests that were now failing. This involved deleting the code to handle the MIPS MSA element-order (which was previously doing an byte-order swap instead of an element-order swap). This left isVectorEltOrderLittleEndian() unused and it was deleted. * Fixed build failures caused by rebasing beyond r194467-r194472. These build failures involved the bset, bneg, and bclr instructions added in these commits using lowerMSASplatImm() in a way that was no longer valid after this patch. Some of these were fixed by calling SelectionDAG::getConstant() instead, others were fixed by a new function getBuildVectorSplat() that provided the removed functionality of lowerMSASplatImm() in a more sensible way. Reviewers: bkramer Reviewed By: bkramer CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1973 llvm-svn: 194811
* Fix some assert messages to say the correct opcode name. Looks like one ↵Craig Topper2013-10-061-7/+7
| | | | | | assert got copy and pasted to many places. llvm-svn: 192078
* Add OPC_CheckChildSame0-3 to the DAG isel matcher. This replaces sequences ↵Craig Topper2013-10-051-0/+27
| | | | | | of MoveChild, CheckSame, MoveParent. Saves 846 bytes from the X86 DAG isel matcher, ~300 from ARM, ~840 from Hexagon. llvm-svn: 192026
* Debug info: Don't crash in SelectionDAGISel when a vreg that is beingAdrian Prantl2013-10-051-3/+7
| | | | | | | | pointed to by a dbg_value belonging to a function argument is eliminated during instruction selection. rdar://problem/15094721. llvm-svn: 192011
* Revert r191940 to see if it fixes the build bots.Craig Topper2013-10-041-27/+0
| | | | llvm-svn: 191941
* Add OPC_CheckChildSame0-3 to the DAG isel matcher. This replaces sequences ↵Craig Topper2013-10-041-0/+27
| | | | | | of MoveChild, CheckSame, MoveParent. Saves 846 bytes from the X86 DAG isel matcher, ~300 from ARM, ~840 from Hexagon. llvm-svn: 191940
* Remove several unused variables.Rafael Espindola2013-10-011-1/+0
| | | | | | Patch by Alp Toker. llvm-svn: 191757
* Added temp flag -misched-bench for staging in default changes.Andrew Trick2013-09-261-1/+1
| | | | llvm-svn: 191423
* whitespaceAndrew Trick2013-09-261-2/+2
| | | | llvm-svn: 191422
* [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
* 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
* Debug info: Fix PR16736 and rdar://problem/14990587.Adrian Prantl2013-09-161-1/+1
| | | | | | | A DBG_VALUE is register-indirect iff the first operand is a register _and_ the second operand is an immediate. llvm-svn: 190821
* [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
* 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-201-4/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud