summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Move DataLayout back to the TargetMachine from TargetSubtargetInfoEric Christopher2015-01-261-2/+2
| | | | | | | | | | | | | | | | | | | derived classes. Since global data alignment, layout, and mangling is often based on the DataLayout, move it to the TargetMachine. This ensures that global data is going to be layed out and mangled consistently if the subtarget changes on a per function basis. Prior to this all targets(*) have had subtarget dependent code moved out and onto the TargetMachine. *One target hasn't been migrated as part of this change: R600. The R600 port has, as a subtarget feature, the size of pointers and this affects global data layout. I've currently hacked in a FIXME to enable progress, but the port needs to be updated to either pass the 64-bitness to the TargetMachine, or fix the DataLayout to avoid subtarget dependent features. llvm-svn: 227113
* Remove the uses of getSubtargetImpl from InstrEmitter and removeEric Christopher2014-10-091-8/+6
| | | | | | the now unused TargetMachine variable. llvm-svn: 219379
* Move the complex address expression out of DIVariable and into an extraAdrian Prantl2014-10-011-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-8/+3
| | | | | | "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-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* SelectionDAG: Remove #if NDEBUG from check for a post-isel hookTom Stellard2014-09-251-2/+0
| | | | | | | | | | | | | | The InstrEmitter will skip the check of MI.hasPostISelHook() before calling AdjustInstrPostInstrSelection() when NDEBUG is not defined. This was added in r140228, and I'm not sure if it is intentional or not, but it is a likely source for bugs, because it means with Release+Asserts builds you can forget to set the hasPostISelHook flag on TableGen definitions and AdjustInstrPostInstrSelection() will still be called. llvm-svn: 218458
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-10/+9
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* [SDAG] Don't insert the VRBase into a mapping from SDValues when the defChandler Carruth2014-07-251-6/+10
| | | | | | | doesn't actually correspond to an SDValue at all. Fixes most of the remaining asserts on out-of-range SDValue result numbers. llvm-svn: 213930
* This reapplies r207235 with an additional bugfixes caught by the msanAdrian Prantl2014-04-251-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | buildbot - do not insert debug intrinsics before phi nodes. Debug info for optimized code: Support variables that are on the stack and described by DBG_VALUEs during their lifetime. Previously, when a variable was at a FrameIndex for any part of its lifetime, this would shadow all other DBG_VALUEs and only a single fbreg location would be emitted, which in fact is only valid for a small range and not the entire lexical scope of the variable. The included dbg-value-const-byref testcase demonstrates this. This patch fixes this by Local - emitting dbg.value intrinsics for allocas that are passed by reference - dropping all dbg.declares (they are now fully lowered to dbg.values) SelectionDAG - renamed constructors for SDDbgValue for better readability. - fix UserValue::match() to handle indirect values correctly - not inserting an MMI table entries for dbg.values that describe allocas. - lowering dbg.values that describe allocas into *indirect* DBG_VALUEs. CodeGenPrepare - leaving dbg.values for an alloca were they are (see comment) Other - regenerated/updated instcombine.ll testcase and included source rdar://problem/16679879 http://reviews.llvm.org/D3374 llvm-svn: 207269
* Revert "This reapplies r207130 with an additional testcase+and a missing ↵Adrian Prantl2014-04-251-5/+2
| | | | | | | | check for" This reverts commit 207235 to investigate msan buildbot breakage. llvm-svn: 207250
* This reapplies r207130 with an additional testcase+and a missing check forAdrian Prantl2014-04-251-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AllocaInst that was missing in one location. Debug info for optimized code: Support variables that are on the stack and described by DBG_VALUEs during their lifetime. Previously, when a variable was at a FrameIndex for any part of its lifetime, this would shadow all other DBG_VALUEs and only a single fbreg location would be emitted, which in fact is only valid for a small range and not the entire lexical scope of the variable. The included dbg-value-const-byref testcase demonstrates this. This patch fixes this by Local - emitting dbg.value intrinsics for allocas that are passed by reference - dropping all dbg.declares (they are now fully lowered to dbg.values) SelectionDAG - renamed constructors for SDDbgValue for better readability. - fix UserValue::match() to handle indirect values correctly - not inserting an MMI table entries for dbg.values that describe allocas. - lowering dbg.values that describe allocas into *indirect* DBG_VALUEs. CodeGenPrepare - leaving dbg.values for an alloca were they are (see comment) Other - regenerated/updated instcombine.ll testcase and included source rdar://problem/16679879 http://reviews.llvm.org/D3374 llvm-svn: 207235
* Revert "This reapplies r207130 with an additional testcase+and a missing ↵Adrian Prantl2014-04-251-5/+2
| | | | | | | | check for" Typo in testcase. llvm-svn: 207166
* This reapplies r207130 with an additional testcase+and a missing check forAdrian Prantl2014-04-251-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AllocaInst that was missing in one location. Debug info for optimized code: Support variables that are on the stack and described by DBG_VALUEs during their lifetime. Previously, when a variable was at a FrameIndex for any part of its lifetime, this would shadow all other DBG_VALUEs and only a single fbreg location would be emitted, which in fact is only valid for a small range and not the entire lexical scope of the variable. The included dbg-value-const-byref testcase demonstrates this. This patch fixes this by Local - emitting dbg.value intrinsics for allocas that are passed by reference - dropping all dbg.declares (they are now fully lowered to dbg.values) SelectionDAG - renamed constructors for SDDbgValue for better readability. - fix UserValue::match() to handle indirect values correctly - not inserting an MMI table entries for dbg.values that describe allocas. - lowering dbg.values that describe allocas into *indirect* DBG_VALUEs. CodeGenPrepare - leaving dbg.values for an alloca were they are (see comment) Other - regenerated/updated instcombine.ll testcase and included source rdar://problem/16679879 http://reviews.llvm.org/D3374 llvm-svn: 207165
* Revert "Debug info for optimized code: Support variables that are on the ↵Adrian Prantl2014-04-251-5/+2
| | | | | | | | stack and" This reverts commit 207130 for buildbot breakage. llvm-svn: 207162
* Debug info for optimized code: Support variables that are on the stack andAdrian Prantl2014-04-241-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | described by DBG_VALUEs during their lifetime. Previously, when a variable was at a FrameIndex for any part of its lifetime, this would shadow all other DBG_VALUEs and only a single fbreg location would be emitted, which in fact is only valid for a small range and not the entire lexical scope of the variable. The included dbg-value-const-byref testcase demonstrates this. This patch fixes this by Local - emitting dbg.value intrinsics for allocas that are passed by reference - dropping all dbg.declares (they are now fully lowered to dbg.values) SelectionDAG - renamed constructors for SDDbgValue for better readability. - fix UserValue::match() to handle indirect values correctly - not inserting an MMI table entries for dbg.values that describe allocas. - lowering dbg.values that describe allocas into *indirect* DBG_VALUEs. CodeGenPrepare - leaving dbg.values for an alloca were they are (see comment) Other - regenerated/updated instcombine-intrinsics testcase and included source rdar://problem/16679879 http://reviews.llvm.org/D3374 llvm-svn: 207130
* [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-9/+9
| | | | | | instead of comparing to nullptr. llvm-svn: 206142
* [c++11] Range'ify use list loops in InstrEmitter.Jim Grosbach2014-04-111-9/+3
| | | | llvm-svn: 206015
* Make consistent use of MCPhysReg instead of uint16_t throughout the tree.Craig Topper2014-04-041-1/+1
| | | | llvm-svn: 205610
* Make stackmap machineinstrs clobber the scratch regs too.Andrew Trick2014-03-051-4/+10
| | | | | | | | | | | | | Patchpoints already did this. Doing it for stackmaps is a convenience for the runtime in the event that it needs to scratch register to patch or perform a runtime call thunk. Unlike patchpoints, we just assume the AnyRegCC calling convention. This is the only language and target independent calling convention specific to stackmaps so makes sense. Although the calling convention is not currently used to select the scratch registers. llvm-svn: 202943
* Always let value types influence register classes.Jakob Stoklund Olesen2014-01-141-4/+13
| | | | | | | | | | | | | | | | | | | | | When creating a virtual register for a def, the value type should be used to pick the register class. If we only use the register class constraint on the instruction, we might pick a too large register class. Some registers can store values of different sizes. For example, the x86 xmm registers can hold f32, f64, and 128-bit vectors. The three different value sizes are represented by register classes with identical register sets: FR32, FR64, and VR128. These register classes have different spill slot sizes, so it is important to use the right one. The register class constraint on an instruction doesn't necessarily care about the size of the value its defining. The value type determines that. This fixes a problem where InstrEmitter was picking 32-bit register classes for 64-bit values on SPARC. llvm-svn: 199187
* Fix patchpoint comments.Andrew Trick2013-11-191-1/+2
| | | | llvm-svn: 195103
* [Stackmap] Materialize the jump address within the patchpoint noop slide.Juergen Ributzka2013-11-091-1/+11
| | | | | | | | | | | | | | | This patch moves the jump address materialization inside the noop slide. This enables patching of the materialization itself or its complete removal. This patch also adds the ability to define scratch registers that can be used safely by the code called from the patchpoint intrinsic. At least one scratch register is required, because that one is used for the materialization of the jump address. This patch depends on D2009. Differential Revision: http://llvm-reviews.chandlerc.com/D2074 Reviewed by Andy llvm-svn: 194306
* [Stackmap] Add AnyReg calling convention support for patchpoint intrinsic.Juergen Ributzka2013-11-081-7/+18
| | | | | | | | | | | | | | The idea of the AnyReg Calling Convention is to provide the call arguments in registers, but not to force them to be placed in a paticular order into a specified set of registers. Instead it is up tp the register allocator to assign any register as it sees fit. The same applies to the return value (if applicable). Differential Revision: http://llvm-reviews.chandlerc.com/D2009 Reviewed by Andy llvm-svn: 194293
* Reapply an improved version of r180816/180817.Adrian Prantl2013-07-091-1/+7
| | | | | | | | | | | | | | | Change the informal convention of DBG_VALUE machine instructions so that we can express a register-indirect address with an offset of 0. The old convention was that a DBG_VALUE is a register-indirect value if the offset (operand 1) is nonzero. The new convention is that a DBG_VALUE is register-indirect if the first operand is a register and the second operand is an immediate. For plain register values the combination reg, reg is used. MachineInstrBuilder::BuildMI knows how to build the new DBG_VALUES. rdar://problem/13658587 llvm-svn: 185966
* Debug Info: Simplify Frame Index handling in DBG_VALUE Machine InstructionsDavid Blaikie2013-06-161-2/+2
| | | | | | | | | | | | | | | | | | | | Rather than using the full power of target-specific addressing modes in DBG_VALUEs with Frame Indicies, simply use Frame Index + Offset. This reduces the complexity of debug info handling down to two representations of values (reg+offset and frame index+offset) rather than three or four. Ideally we could ensure that frame indicies had been eliminated by the time we reached an assembly or dwarf generation, but I haven't spent the time to figure out where the FIs are leaking through into that & whether there's a good place to convert them. Some FI+offset=>reg+offset conversion is done (see PrologEpilogInserter, for example) which is necessary for some SelectionDAG assumptions about registers, I believe, but it might be possible to make this a more thorough conversion & ensure there are no remaining FIs no matter how instruction selection is performed. llvm-svn: 184066
* Temporarily revert "Change the informal convention of DBG_VALUE so that we ↵Adrian Prantl2013-04-301-7/+1
| | | | | | | | | | can express a" because it breaks some buildbots. This reverts commit 180816. llvm-svn: 180819
* Change the informal convention of DBG_VALUE so that we can express aAdrian Prantl2013-04-301-1/+7
| | | | | | | | | | | | register-indirect address with an offset of 0. It used to be that a DBG_VALUE is a register-indirect value if the offset (operand 1) is nonzero. The new convention is that a DBG_VALUE is register-indirect if the first operand is a register and the second operand is an immediate. For plain registers use the combination reg, reg. rdar://problem/13658587 llvm-svn: 180816
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-1/+1
| | | | | | | | | | | | | | | | | | | | | 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
* Use MachineInstrBuilder in InstrEmitter.Jakob Stoklund Olesen2012-12-201-76/+66
| | | | | | | | | | | | This is supposed to be a mechanical change with no functional effects. InstrEmitter can generate all types of MachineOperands which revealed that MachineInstrBuilder was missing a few methods, added by this patch. Besides providing a context pointer to MI::addOperand(), MachineInstrBuilder seems like a better fit for this code. llvm-svn: 170712
* Change TargetLowering::getRegClassFor to take an MVT, instead of EVT.Patrik Hagglund2012-12-131-7/+9
| | | | | | | | | | | | 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-8/+6
| | | | llvm-svn: 169854
* Change TargetLowering::getRegClassFor to take an MVT, instead of EVT.Patrik Hagglund2012-12-111-6/+8
| | | | | | | | | 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-4/+4
| | | | | | | | | | | | | | | | | 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
* [inline asm] Get the mayLoad/mayStore directly from the MIOp_ExtraInfo operand.Chad Rosier2012-10-301-8/+2
| | | | llvm-svn: 167050
* [inline asm] Implement mayLoad and mayStore for inline assembly. In general,Chad Rosier2012-10-301-0/+7
| | | | | | | | | | the MachineInstr MayLoad/MayLoad flags are based on the tablegen implementation. For inline assembly, however, we need to compute these based on the constraints. Revert r166929 as this is no longer needed, but leave the test case in place. rdar://12033048 and PR13504 llvm-svn: 167040
* Move TargetData to DataLayout.Micah Villmow2012-10-081-3/+3
| | | | llvm-svn: 165402
* Fix PR11985Michael Liao2012-09-121-0/+1
| | | | | | | | | | | - BlockAddress has no support of BA + offset form and there is no way to propagate that offset into machine operand; - Add BA + offset support and a new interface 'getTargetBlockAddress' to simplify target block address forming; - All targets are modified to use new interface and X86 backend is enhanced to support BA + offset addressing. llvm-svn: 163743
* Remove an overly-aggressive assertion. The code following this assertion ↵Owen Anderson2012-09-121-2/+0
| | | | | | already knows how to handle the case where DstRC was NULL, so it's not actually protecting us from anything, and this pattern can come up when using unknown_class operands in the SelectionDAG. llvm-svn: 163736
* Add a new optimization pass: Stack Coloring, that merges disjoint static ↵Nadav Rotem2012-09-061-0/+11
| | | | | | | | allocations (allocas). Allocas are known to be disjoint if they are marked by disjoint lifetime markers (@llvm.lifetime.XXX intrinsics). llvm-svn: 163299
* Add MachineInstr::tieOperands, remove setIsTied().Jakob Stoklund Olesen2012-08-311-6/+2
| | | | | | | | | | | Manage tied operands entirely internally to MachineInstr. This makes it possible to change the representation of tied operands, as I will do shortly. The constraint that tied uses and defs must be in the same order was too restrictive. llvm-svn: 163021
* Don't enforce ordered inline asm operands.Jakob Stoklund Olesen2012-08-311-10/+0
| | | | | | | | | I was too optimistic, inline asm can have tied operands that don't follow the def order. Fixes PR13742. llvm-svn: 162998
* Verify the order of tied operands in inline asm.Jakob Stoklund Olesen2012-08-291-0/+12
| | | | | | | | | | | | | | When there are multiple tied use-def pairs on an inline asm instruction, the tied uses must appear in the same order as the defs. It is possible to write an LLVM IR inline asm instruction that breaks this constraint, but there is no reason for a front end to emit the operands out of order. The gnu inline asm syntax specifies tied operands as a single read/write constraint "+r", so ouf of order operands are not possible. llvm-svn: 162878
* Set the isTied flags when building INLINEASM MachineInstrs.Jakob Stoklund Olesen2012-08-291-4/+21
| | | | | | | | For normal instructions, isTied() is set automatically by addOperand(), based on MCInstrDesc, but inline asm has tied operands outside the descriptor. llvm-svn: 162869
* Avoid including explicit uses when counting SDNode imp-uses.Jakob Stoklund Olesen2012-08-241-3/+6
| | | | | | | It is legal to have a register node as an explicit operand, it shouldn't be counted as an implicit use. llvm-svn: 162591
* Add SelectionDAG::getTargetIndex.Jakob Stoklund Olesen2012-08-071-0/+4
| | | | | | | This adds support for TargetIndex operands during isel. The meaning of these (index, offset, flags) operands is entirely defined by the target. llvm-svn: 161453
* InstrEmitter::EmitSubregNode() optimize extract_subreg in this case:Evan Cheng2012-07-111-1/+2
| | | | | | | | | | | | | | | | | r1025 = s/zext r1024, 4 r1026 = extract_subreg r1025, 4 to a copy: r1026 = copy r1024 This is correct. However it uses TII->isCoalescableExtInstr() which can return true for instructions which essentially does a sext_in_reg so this can end up with an illegal copy where the source and destination register classes do not match. Add a check to avoid it. Sorry, no test case possible at this time. rdar://11849816 llvm-svn: 160059
* Allow trailing physreg RegisterSDNode operands on non-variadic instructions.Jakob Stoklund Olesen2012-07-041-7/+27
| | | | | | | | | | | | | | | Also allow trailing register mask operands on non-variadic both MachineSDNodes and MachineInstrs. The extra physreg RegisterSDNode operands are added to the MI as <imp-use> operands. This makes it possible to have non-variadic call instructions. Call and return instructions really are non-variadic, the argument registers should only be used implicitly - they are not part of the encoding. llvm-svn: 159727
* Clear kill flags in InstrEmitter::EmitSubregNode().Jakob Stoklund Olesen2012-06-291-0/+1
| | | | | | | When a local virtual register is made global, make sure to clear any existing kill flags. llvm-svn: 159461
* Add an MF argument to TRI::getPointerRegClass() and TII::getRegClass().Jakob Stoklund Olesen2012-05-071-3/+3
| | | | | | | | | | | | | The getPointerRegClass() hook can return register classes that depend on the calling convention of the current function (ptr_rc_tailcall). So far, we have been able to infer the calling convention from the subtarget alone, but as we add support for multiple calling conventions per target, that no longer works. Patch by Yiannis Tsiouris! llvm-svn: 156328
OpenPOWER on IntegriCloud