summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/TargetInstrInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* MachineInstr: Change return value of getOpcode() to unsigned.Matthias Braun2015-05-181-2/+2
| | | | | | | | | This was previously returning int. However there are no negative opcode numbers and more importantly this was needlessly different from MCInstrDesc::getOpcode() (which even is the value returned here) and SDValue::getOpcode()/SDNode::getOpcode(). llvm-svn: 237611
* Commute the internal flag on MachineOperands.Pete Cooper2015-04-301-0/+4
| | | | | | | | | | | | | | When commuting a thumb instruction in the size reduction pass, thumb instructions are represented as a bundle and so some operands may be marked as internal. The internal flag has to move with the operand when commuting. This test is sensitive to register allocation so can't specifically check that this error was happening, but so long as it continues to pass with -verify then hopefully its still ok. rdar://problem/20752113 llvm-svn: 236282
* Fix for PR23103. Correctly propagate the 'IsUndef' flag to the register ↵Andrea Di Biagio2015-04-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | operands of a commuted instruction. Revision 220239 exposed a latent bug in method 'TargetInstrInfo::commuteInstruction'. When commuting the operands of a machine instruction, method 'commuteInstruction' didn't correctly propagate the 'IsUndef' flag to the register operands of the new (commuted) instruction. Before this patch, the following instruction: %vreg4<def> = VADDSDrr %vreg14, %vreg5<undef>; FR64:%vreg4,%vreg14,%vreg5 was wrongly converted by method 'commuteInstruction' into: %vreg4<def> = VADDSDrr %vreg5, %vreg14<undef>; FR64:%vreg4,%vreg5,%vreg14 The correct instruction should have been: %vreg4<def> = VADDSDrr %vreg5<undef>, %vreg14; FR64:%vreg4,%vreg5,%vreg14 This patch fixes the problem in method 'TargetInstrInfo::commuteInstruction'. When swapping the operands of a machine instruction, we now make sure that 'IsUndef' flags are correctly set. Added test case 'pr23103.ll'. Differential Revision: http://reviews.llvm.org/D9406 llvm-svn: 236258
* Use the cached subtarget off of the machine function.Eric Christopher2015-03-191-8/+7
| | | | llvm-svn: 232782
* ArrayRefize memory operand folding. NFC.Benjamin Kramer2015-02-281-18/+12
| | | | llvm-svn: 230846
* Move DataLayout back to the TargetMachine from TargetSubtargetInfoEric Christopher2015-01-261-1/+1
| | | | | | | | | | | | | | | | | | | 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
* Fix include ordering, NFC.Michael Kuperstein2015-01-081-1/+1
| | | | llvm-svn: 225439
* Move SPAdj logic from PEI into the targets (NFC)Michael Kuperstein2015-01-081-0/+23
| | | | | | | | | | | | PEI tries to keep track of how much starting or ending a call sequence adjusts the stack pointer by, so that it can resolve frame-index references. Currently, it takes a very simplistic view of how SP adjustments are done - both FrameStartOpcode and FrameDestroyOpcode adjust it exactly by the amount written in its first argument. This view is in fact incorrect for some targets (e.g. due to stack re-alignment, or because it may want to adjust the stack pointer in multiple steps). However, that doesn't cause breakage, because most targets (the only in-tree exception appears to be 32-bit ARM) rely on being able to simplify the call frame pseudo-instructions earlier, so this code is never hit. Moving the computation into TargetInstrInfo allows targets to override the way the adjustment is computed if they need to have a non-zero SPAdj. Differential Revision: http://reviews.llvm.org/D6863 llvm-svn: 225437
* Fix a lot of confusion around inserting nops on empty functions.Rafael Espindola2014-09-151-0/+4
| | | | | | | | | | | | | | | | On MachO, and MachO only, we cannot have a truly empty function since that breaks the linker logic for atomizing the section. When we are emitting a frame pointer, the presence of an unreachable will create a cfi instruction pointing past the last instruction. This is perfectly fine. The FDE information encodes the pc range it applies to. If some tool cannot handle this, we should explicitly say which bug we are working around and only work around it when it is actually relevant (not for ELF for example). Given the unreachable we could omit the .cfi_def_cfa_register, but then again, we could also omit the entire function prologue if we wanted to. llvm-svn: 217801
* Change MCSchedModel to be a struct of statically initialized data.Pete Cooper2014-09-021-3/+3
| | | | | | | | This removes static initializers from the backends which generate this data, and also makes this struct match the other Tablegen generated structs in behaviour Reviewed by Andy Trick and Chandler C llvm-svn: 216919
* Add isInsertSubreg property.Quentin Colombet2014-08-201-0/+26
| | | | | | | | | | | | | This patch adds a new property: isInsertSubreg and the related target hooks: TargetIntrInfo::getInsertSubregInputs and TargetInstrInfo::getInsertSubregLikeInputs to specify that a target specific instruction is a (kind of) INSERT_SUBREG. The approach is similar to r215394. <rdar://problem/12702965> llvm-svn: 216139
* Add isExtractSubreg property.Quentin Colombet2014-08-201-0/+23
| | | | | | | | | | | | | This patch adds a new property: isExtractSubreg and the related target hooks: TargetIntrInfo::getExtractSubregInputs and TargetInstrInfo::getExtractSubregLikeInputs to specify that a target specific instruction is a (kind of) EXTRACT_SUBREG. The approach is similar to r215394. <rdar://problem/12702965> llvm-svn: 216130
* Fix a parentheses warning introduced in r215394.Quentin Colombet2014-08-121-2/+2
| | | | llvm-svn: 215459
* Add isRegSequence property.Quentin Colombet2014-08-111-0/+25
| | | | | | | | | | | This patch adds a new property: isRegSequence and the related target hooks: TargetIntrInfo::getRegSequenceInputs and TargetInstrInfo::getRegSequenceLikeInputs to specify that a target specific instruction is a (kind of) REG_SEQUENCE. <rdar://problem/12702965> llvm-svn: 215394
* Have MachineFunction cache a pointer to the subtarget to make lookupsEric Christopher2014-08-051-6/+3
| | | | | | | | | | | 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-6/+11
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* Remove the query for TargetMachine and TargetInstrInfo since we'reEric Christopher2014-07-231-3/+1
| | | | | | already inside TargetInstrInfo. llvm-svn: 213806
* The hazard recognizer only needs a subtarget, not a target machineEric Christopher2014-06-131-1/+1
| | | | | | so make it take one. Fix up all users accordingly. llvm-svn: 210948
* Revert r210613 to conform to coding standards.Eric Christopher2014-06-111-1/+1
| | | | | | Thanks Duncan for noticing. llvm-svn: 210662
* Sort includes.Eric Christopher2014-06-111-1/+1
| | | | llvm-svn: 210613
* [TargetInstrInfo] Fix the implementation of commuteInstruction to match theQuentin Colombet2014-05-081-4/+2
| | | | | | | | | | | | | comment of the API. Relaxes the behavior of TargetInstrInfo::commuteInstruction when TargetInstrInfo::findCommutedOpIndices returns false. Previously TargetInstrInfo triggered a fatal error in such situation whereas based on the comment in the API it should just return nullptr. Indeed the only precondition that should be ensured is that the instruction must be commutable. llvm-svn: 208371
* Break PseudoSourceValue out of the Value hierarchy. It is now the root of ↵Nick Lewycky2014-04-151-4/+8
| | | | | | its own tree containing FixedStackPseudoSourceValue (which you can use isa/dyn_cast on) and MipsCallEntry (which you can't). Anything that needs to use either a PseudoSourceValue* and Value* is strongly encouraged to use a MachinePointerInfo instead. llvm-svn: 206255
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-141-14/+14
| | | | | | instead of comparing to nullptr. llvm-svn: 206142
* Replace PROLOG_LABEL with a new CFI_INSTRUCTION.Rafael Espindola2014-03-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The old system was fairly convoluted: * A temporary label was created. * A single PROLOG_LABEL was created with it. * A few MCCFIInstructions were created with the same label. The semantics were that the cfi instructions were mapped to the PROLOG_LABEL via the temporary label. The output position was that of the PROLOG_LABEL. The temporary label itself was used only for doing the mapping. The new CFI_INSTRUCTION has a 1:1 mapping to MCCFIInstructions and points to one by holding an index into the CFI instructions of this function. I did consider removing MMI.getFrameInstructions completelly and having CFI_INSTRUCTION own a MCCFIInstruction, but MCCFIInstructions have non trivial constructors and destructors and are somewhat big, so the this setup is probably better. The net result is that we don't create temporary labels that are never used. llvm-svn: 203204
* Remove redundant fold call introduced in r195944. Thanks very much to JuergenLang Hames2014-01-021-2/+1
| | | | | | | for pointing this out. llvm-svn: 198341
* Correct think-o in foldPatchpoint. Thanks to Andy Trick for pointing it out.Lang Hames2013-12-071-1/+1
| | | | llvm-svn: 196640
* Refactor a lot of patchpoint/stackmap related code to simplify and make itLang Hames2013-11-291-3/+87
| | | | | | | | | | | | | | | | | | | | | | target independent. Most of the x86 specific stackmap/patchpoint handling was necessitated by the use of the native address-mode format for frame index operands. PEI has now been modified to treat stackmap/patchpoint similarly to DEBUG_INFO, allowing us to use a simple, platform independent register/offset pair for frame indexes on stackmap/patchpoints. Notes: - Folding is now platform independent and automatically supported. - Emiting patchpoints with direct memory references now just involves calling the TargetLoweringBase::emitPatchPoint utility method from the target's XXXTargetLowering::EmitInstrWithCustomInserter method. (See X86TargetLowering for an example). - No more ugly platform-specific operand parsers. This patch shouldn't change the generated output for X86. llvm-svn: 195944
* Added a size field to the stack map record to handle subregister spills.Andrew Trick2013-11-171-0/+31
| | | | | | | | Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
* When folding memory operands, preserve existing MachineMemOperands.Andrew Trick2013-11-141-3/+14
| | | | | | | | | | This comes into play with patchpoint, which can fold multiple operands. Since the patchpoint is already treated as a call, the machine mem operands won't affect anything, and there's nothing to test. But we still want to do the right thing here to be sure that our MIs obey the rules. llvm-svn: 194750
* IfConverter: Use TargetSchedule for instruction latenciesArnold Schwaighofer2013-09-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For targets that have instruction itineraries this means no change. Targets that move over to the new schedule model will use be able the new schedule module for instruction latencies in the if-converter (the logic is such that if there is no itineary we will use the new sched model for the latencies). Before, we queried "TTI->getInstructionLatency()" for the instruction latency and the extra prediction cost. Now, we query the TargetSchedule abstraction for the instruction latency and TargetInstrInfo for the extra predictation cost. The TargetSchedule abstraction will internally call "TTI->getInstructionLatency" if an itinerary exists, otherwise it will use the new schedule model. ATTENTION: Out of tree targets! (I will also send out an email later to LLVMDev) This means, if your target implements unsigned getInstrLatency(const InstrItineraryData *ItinData, const MachineInstr *MI, unsigned *PredCost); and returns a value for "PredCost", you now also need to implement unsigned getPredictationCost(const MachineInstr *MI); (if your target uses the IfConversion.cpp pass) radar://15077010 llvm-svn: 191671
* Machine Model: Add MicroOpBufferSize and resource BufferSize.Andrew Trick2013-06-151-22/+6
| | | | | | | | | | | | | Replace the ill-defined MinLatency and ILPWindow properties with with straightforward buffer sizes: MCSchedMode::MicroOpBufferSize MCProcResourceDesc::BufferSize These can be used to more precisely model instruction execution if desired. Disabled some misched tests temporarily. They'll be reenabled in a few commits. llvm-svn: 184032
* Add static cast to unsigned char whenever a character classification ↵Guy Benyei2013-02-121-1/+1
| | | | | | function is called with a signed char argument, in order to avoid assertions in Windows Debug configuration. llvm-svn: 175006
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-1/+1
| | | | | | | | | | | | | | | | | 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 the guts of TargetInstrInfoImpl into the TargetInstrInfo class.Jakob Stoklund Olesen2012-11-281-8/+659
| | | | | | | The *Impl class no longer serves a purpose now that the super-class implementation is in CodeGen. llvm-svn: 168759
* Move Target{Instr,Register}Info.cpp into lib/CodeGen.Jakob Stoklund Olesen2012-11-281-0/+88
The Target library is not allowed to depend on the large CodeGen library, but the TRI and TII classes provide abstract interfaces that require both caller and callee to link to CodeGen. The implementation files for these classes provide default implementations of some of the hooks. These methods may need to reference CodeGen, so they belong in that library. We already have a number of methods implemented in the TargetInstrInfoImpl sub-class because of that. I will merge that class into the parent next. llvm-svn: 168758
OpenPOWER on IntegriCloud