summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG/FunctionLoweringInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Move the complex address expression out of DIVariable and into an extraAdrian Prantl2014-10-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | argument of the llvm.dbg.declare/llvm.dbg.value intrinsics. Previously, DIVariable was a variable-length field that has an optional reference to a Metadata array consisting of a variable number of complex address expressions. In the case of OpPiece expressions this is wasting a lot of storage in IR, because when an aggregate type is, e.g., SROA'd into all of its n individual members, the IR will contain n copies of the DIVariable, all alike, only differing in the complex address reference at the end. By making the complex address into an extra argument of the dbg.value/dbg.declare intrinsics, all of the pieces can reference the same variable and the complex address expressions can be uniqued across the CU, too. Down the road, this will allow us to move other flags, such as "indirection" out of the DIVariable, too. The new intrinsics look like this: declare void @llvm.dbg.declare(metadata %storage, metadata %var, metadata %expr) declare void @llvm.dbg.value(metadata %storage, i64 %offset, metadata %var, metadata %expr) This patch adds a new LLVM-local tag to DIExpressions, so we can detect and pretty-print DIExpression metadata nodes. What this patch doesn't do: This patch does not touch the "Indirect" field in DIVariable; but moving that into the expression would be a natural next step. http://reviews.llvm.org/D4919 rdar://problem/17994491 Thanks to dblaikie and dexonsmith for reviewing this patch! Note: I accidentally committed a bogus older version of this patch previously. llvm-svn: 218787
* Revert r218778 while investigating buldbot breakage.Adrian Prantl2014-10-011-1/+1
| | | | | | "Move the complex address expression out of DIVariable and into an extra" llvm-svn: 218782
* Move the complex address expression out of DIVariable and into an extraAdrian Prantl2014-10-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | argument of the llvm.dbg.declare/llvm.dbg.value intrinsics. Previously, DIVariable was a variable-length field that has an optional reference to a Metadata array consisting of a variable number of complex address expressions. In the case of OpPiece expressions this is wasting a lot of storage in IR, because when an aggregate type is, e.g., SROA'd into all of its n individual members, the IR will contain n copies of the DIVariable, all alike, only differing in the complex address reference at the end. By making the complex address into an extra argument of the dbg.value/dbg.declare intrinsics, all of the pieces can reference the same variable and the complex address expressions can be uniqued across the CU, too. Down the road, this will allow us to move other flags, such as "indirection" out of the DIVariable, too. The new intrinsics look like this: declare void @llvm.dbg.declare(metadata %storage, metadata %var, metadata %expr) declare void @llvm.dbg.value(metadata %storage, i64 %offset, metadata %var, metadata %expr) This patch adds a new LLVM-local tag to DIExpressions, so we can detect and pretty-print DIExpression metadata nodes. What this patch doesn't do: This patch does not touch the "Indirect" field in DIVariable; but moving that into the expression would be a natural next step. http://reviews.llvm.org/D4919 rdar://problem/17994491 Thanks to dblaikie and dexonsmith for reviewing this patch! llvm-svn: 218778
* Clear PreferredExtendType for in each function-specific state ↵Jiangning Liu2014-09-241-0/+1
| | | | | | FunctionLoweringInfo. llvm-svn: 218364
* Optimize sext/zext insertion algorithm in back-end.Jiangning Liu2014-09-191-0/+25
| | | | | | | | With this optimization, we will not always insert zext for values crossing basic blocks, but insert sext if the users of a value crossing basic block has preference of sign predicate. llvm-svn: 218101
* CodeGen: Handle va_start in the entry blockReid Kleckner2014-09-021-24/+16
| | | | | | | | | Also fix a small copy-paste bug in X86ISelLowering where Chain should have been used in place of DAG.getEntryToken(). Fixes PR20828. llvm-svn: 216929
* Add a const and munge some commentsReid Kleckner2014-08-291-1/+1
| | | | llvm-svn: 216781
* musttail: Forward regparms of variadic functions on x86_64Reid Kleckner2014-08-291-0/+7
| | | | | | | | | | | | | | | | | | | | | | Summary: If a variadic function body contains a musttail call, then we copy all of the remaining register parameters into virtual registers in the function prologue. We track the virtual registers through the function body, and add them as additional registers to pass to the call. Because this is all done in virtual registers, the register allocator usually gives us good code. If the function does a call, however, it will have to spill and reload all argument registers (ew). Forwarding regparms on x86_32 is not implemented because most compilers don't support varargs in 32-bit with regparms. Reviewers: majnemer Subscribers: aemerson, llvm-commits Differential Revision: http://reviews.llvm.org/D5060 llvm-svn: 216780
* ARM / x86_64 varargs: Don't save regparms in prologue without va_startReid Kleckner2014-08-221-0/+8
| | | | | | | | | | | | There's no need to do this if the user doesn't call va_start. In the future, we're going to have thunks that forward these register parameters with musttail calls, and they won't need these spills for handling va_start. Most of the test suite changes are adding va_start calls to existing tests to keep things working. llvm-svn: 216294
* Have MachineFunction cache a pointer to the subtarget to make lookupsEric Christopher2014-08-051-2/+1
| | | | | | | | | | | shorter/easier and have the DAG use that to do the same lookup. This can be used in the future for TargetMachine based caching lookups from the MachineFunction easily. Update the MIPS subtarget switching machinery to update this pointer at the same time it runs. llvm-svn: 214838
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-7/+10
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* [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
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-141-2/+2
| | | | | | instead of comparing to nullptr. llvm-svn: 206142
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-091-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
* [Layering] Move DebugInfo.h into the IR library where its implementationChandler Carruth2014-03-061-1/+1
| | | | | | already lives. llvm-svn: 203046
* [Layering] Move DebugLoc.h into the IR library. The implementationChandler Carruth2014-03-051-1/+1
| | | | | | | | | | | already lived there and it is where it belongs -- this is the in-memory debug location representation. This is just cleanup -- Modules can actually cope with this, but that doesn't make it right. After chatting with folks that have out-of-tree stuff, going ahead and moving the rest of the headers seems preferable. llvm-svn: 202960
* Fix unused variable in FunctionLoweringInfo.cppHans Wennborg2014-03-051-1/+1
| | | | llvm-svn: 202932
* Check for dynamic allocas and inline asm that clobbers sp before buildingHans Wennborg2014-03-051-1/+40
| | | | | | | | | | | | | | | | | | | 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
* Don't put non-static allocas in the static alloca mapReid Kleckner2014-01-311-1/+7
| | | | | | | | Allocas marked inalloca are never static, but we were trying to put them into the static alloca map if they were in the entry block. Also add an assertion in x86 fastisel. llvm-svn: 200593
* [stackprotector] Use analysis from the StackProtector pass for stack layout ↵Josh Magee2013-12-191-9/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | in PEI a nd LocalStackSlot passes. This changes the MachineFrameInfo API to use the new SSPLayoutKind information produced by the StackProtector pass (instead of a boolean flag) and updates a few pass dependencies (to preserve the SSP analysis). The stack layout follows the same approach used prior to this change - i.e., only LargeArray stack objects will be placed near the canary and everything else will be laid out normally. After this change, structures containing large arrays will also be placed near the canary - a case previously missed by the old implementation. Out of tree targets will need to update their usage of MachineFrameInfo::CreateStackObject to remove the MayNeedSP argument. The next patch will implement the rules for sspstrong and sspreq. The end goal is to support ssp-strong stack layout rules. WIP. Differential Revision: http://llvm-reviews.chandlerc.com/D2158 llvm-svn: 197653
* Debug Info: clean up usage of Verify.Manman Ren2013-06-281-1/+4
| | | | | | | | | | | No functionality change. It should suffice to check the type of a debug info metadata, instead of calling Verify. For cases where we know the type of a DI metadata, use assert. Also update testing cases to make them conform to the format of DI classes. llvm-svn: 185135
* Don't cache the TLI object since we have access to it through TargetMachine ↵Bill Wendling2013-06-191-6/+8
| | | | | | already. llvm-svn: 184346
* Don't cache the TargetLoweringInfo object inside of the FunctionLowering object.Bill Wendling2013-06-061-17/+18
| | | | | | | | The TargetLoweringInfo object is owned by the TargetMachine. In the future, the TargetMachine object may change, which may also change the TargetLoweringInfo object. llvm-svn: 183356
* Revert 172027 and 174336. Remove diagnostics about over-aligned stack objects.Bob Wilson2013-02-081-2/+1
| | | | | | | | | | | | Aside from the question of whether we report a warning or an error when we can't satisfy a requested stack object alignment, the current implementation of this is not good. We're not providing any source location in the diagnostics and the current warning is not connected to any warning group so you can't control it. We could improve the source location somewhat, but we can do a much better job if this check is implemented in the front-end, so let's do that instead. <rdar://problem/13127907> llvm-svn: 174741
* Stack Alignment: throw error if we can't satisfy the minimal alignmentManman Ren2013-01-101-1/+2
| | | | | | | | | | | | | | | | | | requirement when creating stack objects in MachineFrameInfo. Add CreateStackObjectWithMinAlign to throw error when the minimal alignment can't be achieved and to clamp the alignment when the preferred alignment can't be achieved. Same is true for CreateVariableSizedObject. Will not emit error in CreateSpillStackObject or CreateStackObject. As long as callers of CreateStackObject do not assume the object will be aligned at the requested alignment, we should not have miscompile since later optimizations which look at the object's alignment will have the correct information. rdar://12713765 llvm-svn: 172027
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-7/+7
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
* Remove the Function::getRetAttributes method in favor of using the ↵Bill Wendling2012-12-301-2/+1
| | | | | | AttributeSet accessor method. llvm-svn: 171256
* Change TargetLowering::RegisterTypeForVT to contain MVTs, instead ofPatrik Hagglund2012-12-191-1/+1
| | | | | | EVTs. llvm-svn: 170535
* Change TargetLowering::getRegClassFor to take an MVT, instead of EVT.Patrik Hagglund2012-12-131-2/+2
| | | | | | | | | | | | Accordingly, add helper funtions getSimpleValueType (in parallel to getValueType) in SDValue, SDNode, and TargetLowering. This is the first, in a series of patches. This is the second attempt. In the first attempt (r169837), a few getSimpleVT() were hoisted too far, detected by bootstrap failures. llvm-svn: 170104
* Revert EVT->MVT changes, r169836-169851, due to buildbot failures.Patrik Hagglund2012-12-111-2/+2
| | | | llvm-svn: 169854
* Change TargetLowering::RegisterTypeForVT to contain MVTs, instead ofPatrik Hagglund2012-12-111-1/+1
| | | | | | EVTs. llvm-svn: 169848
* Change TargetLowering::getRegClassFor to take an MVT, instead of EVT.Patrik Hagglund2012-12-111-2/+2
| | | | | | | | | Accordingly, add helper funtions getSimpleValueType (in parallel to getValueType) in SDValue, SDNode, and TargetLowering. This is the first, in a series of patches. llvm-svn: 169837
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-12/+12
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* Move TargetData to DataLayout.Micah Villmow2012-10-081-3/+3
| | | | llvm-svn: 165402
* Add a new optimization pass: Stack Coloring, that merges disjoint static ↵Nadav Rotem2012-09-061-1/+1
| | | | | | | | allocations (allocas). Allocas are known to be disjoint if they are marked by disjoint lifetime markers (@llvm.lifetime.XXX intrinsics). llvm-svn: 163299
* Move lib/Analysis/DebugInfo.cpp to lib/VMCore/DebugInfo.cpp andBill Wendling2012-06-281-1/+1
| | | | | | | | | include/llvm/Analysis/DebugInfo.h to include/llvm/DebugInfo.h. The reasoning is because the DebugInfo module is simply an interface to the debug info MDNodes and has nothing to do with analysis. llvm-svn: 159312
* Tabs, formatting and long lines oh my!Eric Christopher2012-02-241-4/+6
| | | | llvm-svn: 151334
* More newline cleanups.Eric Christopher2012-02-231-1/+1
| | | | llvm-svn: 151235
* Properly emit _fltused with FastISel. Refactor to share code with SDAG.Michael J. Spencer2012-02-221-0/+25
| | | | | | Patch by Joe Groff! llvm-svn: 151183
* Remove the eh.exception and eh.selector intrinsics. Also remove a hack to copyBill Wendling2012-01-311-28/+0
| | | | | | | over the catch information. The catch information is now tacked to the invoke instruction. llvm-svn: 149326
* An array of chars of length 8 will also cause the stack protector to be insertedBill Wendling2011-11-021-1/+1
| | | | | | | | into the function. Reflect that here so that the array will be placed next to the SP. <rdar://problem/10128329> llvm-svn: 143590
* Directly point debug info to the stack slot of the arugment, instead of ↵Devang Patel2011-09-081-6/+4
| | | | | | trying to keep track of vreg in which it the arugment is copied. The LiveDebugVariable can keep track of variable's ranges. llvm-svn: 139330
* Add the support in code-gen for the landingpad instruction lowering.Bill Wendling2011-08-171-0/+31
| | | | | | | | | | The landingpad instruction is lowered into the EXCEPTIONADDR and EHSELECTION SDNodes. The information from the landingpad instruction is harvested by the 'AddLandingPadInfo' function. The new EH uses the current EH scheme in the back-end. This will change once we switch over to the new scheme. (Reviewed by Jakob!) llvm-svn: 137880
* Revert r136253, r136263, r136269, r136313, r136325, r136326, r136329, r136338,Bill Wendling2011-07-301-34/+0
| | | | | | | r136339, r136341, r136369, r136387, r136392, r136396, r136429, r136430, r136444, r136445, r136446, r136253 pending review. llvm-svn: 136556
* Add the AddLandingPadInfo function.Bill Wendling2011-07-281-0/+34
| | | | | | | AddLandingPadInfo takes a landingpad instruction and grabs all of the information from it that it needs for EH table generation. llvm-svn: 136429
* land David Blaikie's patch to de-constify Type, with a few tweaks.Chris Lattner2011-07-181-3/+3
| | | | llvm-svn: 135375
* Add a parameter to CCState so that it can access the MachineFunction.Eric Christopher2011-06-081-5/+6
| | | | | | | | No functional change. Part of PR6965 llvm-svn: 132763
* Make codegen able to handle values of empty types. This is one wayRafael Espindola2011-05-131-0/+4
| | | | | | to fix PR9900. I will keep it open until sable is able to comment on it. llvm-svn: 131294
* Avoid extra vreg copies for arguments passed in registers. Specifically, ↵Eli Friedman2011-05-051-26/+0
| | | | | | this can make MachineCSE more effective in some cases (especially in small functions). PR8361 / part of rdar://problem/8259436 . llvm-svn: 130928
* There are times when the landing pad won't have a call to 'eh.selector' inBill Wendling2011-03-031-9/+23
| | | | | | | | | | | | | | it. It's been assumed up til now that it would be in its immediate successor. However, this isn't necessarily the case. It could be in one of its successor's successors. Modify the code to more thoroughly check for an 'eh.selector' call in successors. It only looks at a successor if we get there as a result of an unconditional branch. Testcase ObjC/exceptions-4.m in r126968. llvm-svn: 126969
OpenPOWER on IntegriCloud