summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/MachineInstr.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove dead function.Jakob Stoklund Olesen2013-07-051-26/+0
| | | | llvm-svn: 185731
* Debug Info: clean up usage of Verify.Manman Ren2013-06-281-1/+3
| | | | | | | | | | | 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
* Remove liveout lists from MachineRegisterInfo.Jakob Stoklund Olesen2013-02-051-2/+2
| | | | | | | | All targets are now adding return value registers as implicit uses on return instructions, and there is no longer a need for the live out lists. llvm-svn: 174417
* ScheduleDAG: colorize the DOT graph and improve formatting.Andrew Trick2013-01-251-1/+5
| | | | llvm-svn: 173431
* For inline asm:Eric Christopher2013-01-111-1/+5
| | | | | | | | | | | - recognize string "{memory}" in the MI generation - mark as mayload/maystore when there's a memory clobber constraint. PR14859. Patch by Krzysztof Parzyszek llvm-svn: 172228
* Allow hasProperty() to be called on bundle-internal instructions.Jakob Stoklund Olesen2013-01-101-0/+1
| | | | | | | | | | | | | When calling hasProperty() on an instruction inside a bundle, it should always behave as if IgnoreBundle was passed, and just return properties for the current instruction. Only attempt to aggregate bundle properties whan asked about the bundle header. The assertion fires on existing ARM test cases without this fix. llvm-svn: 172082
* Support headerless bundles in MachineInstr::hasProperty().Jakob Stoklund Olesen2013-01-101-7/+5
| | | | | | This function can still work without a BUNDLE header instruction. llvm-svn: 172029
* Don't print bundle flags.Jakob Stoklund Olesen2013-01-091-1/+2
| | | | | | | The bundle flags are used by MachineBasicBlock::print(), they don't need to clutter up individual MachineInstrs. llvm-svn: 171986
* Don't require BUNDLE headers in MachineInstr::getBundleSize().Jakob Stoklund Olesen2013-01-091-10/+5
| | | | | | | | It is possible to build MI bundles that don't begin with a BUNDLE header. Add support for such bundles, counting all instructions inside the bundle. llvm-svn: 171985
* Fix a typo in MachineInstr::unbundleFromSucc() method.Sergei Larin2013-01-091-1/+1
| | | | llvm-svn: 171983
* Pack MachineOperand bitfields better.Jakob Stoklund Olesen2013-01-071-1/+1
| | | | | | Previously, 4 bits were unused. llvm-svn: 171814
* Pack MachineInstr fields better.Jakob Stoklund Olesen2013-01-071-5/+3
| | | | | | This shrinks MachineInstr to 64 bytes (from 72). llvm-svn: 171813
* Don't call destructors on MachineInstr and MachineOperand.Jakob Stoklund Olesen2013-01-051-20/+1
| | | | | | | | | | | | | | | | | | | | The series of patches leading up to this one makes llc -O0 run 8% faster. When deallocating a MachineFunction, there is no need to visit all MachineInstr and MachineOperand objects to deallocate them. All their memory come from a BumpPtrAllocator that is about to be purged, and they have empty destructors anyway. This only applies when deallocating the MachineFunction. DeleteMachineInstr() should still be used to recycle MI memory during the codegen passes. Remove the LeakDetector support for MachineInstr. I've never seen it used before, and now it definitely doesn't work. With this patch, leaked MachineInstrs would be much less of a problem since all of their memory will be reclaimed by ~MachineFunction(). llvm-svn: 171599
* Use ArrayRecycler for MachineInstr operand lists.Jakob Stoklund Olesen2013-01-051-74/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of an std::vector<MachineOperand>, use MachineOperand arrays from an ArrayRecycler living in MachineFunction. This has several advantages: - MachineInstr now has a trivial destructor, making it possible to delete them in batches when destroying MachineFunction. This will be enabled in a later patch. - Bypassing malloc() and free() can be faster, depending on the system library. - MachineInstr objects and their operands are allocated from the same BumpPtrAllocator, so they will usually be next to each other in memory, providing better locality of reference. - Reduce MachineInstr footprint. A std::vector is 24 bytes, the new operand array representation only uses 8+4+1 bytes in MachineInstr. - Better control over operand array reallocations. In the old representation, the use-def chains would be reordered whenever a std::vector reached its capacity. The new implementation never changes the use-def chain order. Note that some decisions in the code generator depend on the use-def chain orders, so this patch may cause different assembly to be produced in a few cases. llvm-svn: 171598
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-8/+8
| | | | | | | | | | | | | | | | | | | | | 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 a special case that doesn't seem necessary any longer.Jakob Stoklund Olesen2012-12-221-13/+2
| | | | | | | Back when this exception was added, it was skipping a lot more code, but now it just looks like a premature optimization. llvm-svn: 170989
* Use getNumOperands() instead of Operands.size().Jakob Stoklund Olesen2012-12-221-11/+11
| | | | | | | The representation of the Operands array is going to change soon so it can be allocated from a BumpPtrAllocator. llvm-svn: 170988
* Require the two-argument MI::addOperand(MF, MO) for dangling instructions.Jakob Stoklund Olesen2012-12-201-1/+9
| | | | | | | | | | | Instructions that are inserted in a basic block can still be decorated with addOperand(MO). Make the two-argument addOperand() function contain the actual implementation. This function will now always have a valid MF reference that it can use for memory allocation. llvm-svn: 170798
* Add an MF argument to MI::copyImplicitOps().Jakob Stoklund Olesen2012-12-201-2/+3
| | | | | | | | | This function is often used to decorate dangling instructions, so a context reference is required to allocate memory for the operands. Also add a corresponding MachineInstrBuilder method. llvm-svn: 170797
* Use two-arg addOperand(MF, MO) internally in MachineInstr when possible.Jakob Stoklund Olesen2012-12-201-7/+7
| | | | llvm-svn: 170796
* Remove two dead functions.Jakob Stoklund Olesen2012-12-201-35/+0
| | | | llvm-svn: 170766
* Use bidirectional bundle flags to simplify important functions.Jakob Stoklund Olesen2012-12-181-10/+0
| | | | | | | | | | | The bundle_iterator::operator++ function now doesn't need to dig out the basic block and check against end(). It can use the isBundledWithSucc() flag to find the last bundled instruction safely. Similarly, MachineInstr::isBundled() no longer needs to look at iterators etc. It only has to look at flags. llvm-svn: 170473
* Verify bundle flag consistency when setting them.Jakob Stoklund Olesen2012-12-181-0/+4
| | | | | | | Now that the bundle flag aware APIs are all in place, it is possible to continuously verify the flag consistency. llvm-svn: 170465
* Don't allow the automatically updated MI flags to be set directly.Jakob Stoklund Olesen2012-12-181-2/+2
| | | | | | | | | | | The bundle-related MI flags need to be kept in sync with the neighboring instructions. Don't allow the bulk flag-setting setFlags() function to change them. Also don't copy MI flags when cloning an instruction. The clone's bundle flags will be set when it is explicitly inserted into a bundle. llvm-svn: 170459
* Tighten up the erase/remove API for bundled instructions.Jakob Stoklund Olesen2012-12-171-31/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most code is oblivious to bundles and uses the MBB::iterator which only visits whole bundles. MBB::erase() operates on whole bundles at a time as before. MBB::remove() now refuses to remove bundled instructions. It is not safe to remove all instructions in a bundle without deleting them since there is no way of returning pointers to all the removed instructions. MBB::remove_instr() and MBB::erase_instr() will now update bundle flags correctly, lifting individual instructions out of bundles while leaving the remaining bundle intact. The MachineInstr convenience functions are updated so eraseFromParent() erases a whole bundle as before eraseFromBundle() erases a single instruction, leaving the rest of its bundle. removeFromParent() refuses to operate on bundled instructions, and removeFromBundle() lifts a single instruction out of its bundle. These functions will no longer accidentally split or coalesce bundles - bundle flags are updated to preserve the existing bundling, and explicit bundleWith* / unbundleFrom* functions should be used to change the instruction bundling. This API update is still a work in progress. I am going to update APIs first so they maintain bundle flags automatically when possible. Then I'll add stricter verification of the bundle flags. llvm-svn: 170384
* Add higher-level API for dealing with bundled MachineInstrs.Jakob Stoklund Olesen2012-12-071-0/+32
| | | | | | | | | | | | | | | | | | | | | This is still a work in progress. The purpose is to make bundling and unbundling operations explicit, and to catch errors where bundles are broken or created inadvertently. The old IsInsideBundle flag is replaced by two MI flags: BundledPred which has the same meaning as IsInsideBundle, and BundledSucc which is set on instructions that are bundled with a successor. Having two flags provdes redundancy to detect when a bundle is inadvertently torn by a splice() or insert(), and it makes it possible to write bundle iterators that don't need to peek at adjacent instructions. The new flags can't be manipulated directly (once setIsInsideBundle is gone). Instead there are MI functions to make and break bundle bonds. The setIsInsideBundle function will be removed in a future commit. It should be replaced by bundleWithPred(). llvm-svn: 169583
* Remove unused MachineInstr constructors.Jakob Stoklund Olesen2012-12-051-27/+0
| | | | | | | | A MachineInstr can only ever be constructed by CreateMachineInstr() and CloneMachineInstr(), and those factories don't use the removed constructors. llvm-svn: 169395
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-15/+15
| | | | | | | | | | | | | | | | | 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
* Check that iterator I is not the end iterator.Akira Hatanaka2012-10-311-2/+3
| | | | llvm-svn: 167086
* Remove unused MachineInstr constructors that don't take a DebugLoc argument.Craig Topper2012-10-071-29/+0
| | | | llvm-svn: 165382
* Fix PR11985Michael Liao2012-09-121-2/+4
| | | | | | | | | | | - 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
* Release build: guard dump functions withManman Ren2012-09-111-1/+1
| | | | | | | | "#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)" No functional change. Update r163339. llvm-svn: 163653
* Release build: guard dump functions with "ifndef NDEBUG"Manman Ren2012-09-061-0/+2
| | | | | | No functional change. llvm-svn: 163339
* Cleanup a few magic numbers.Chad Rosier2012-09-051-1/+1
| | | | llvm-svn: 163263
* [ms-inline asm] We only need one bit to represent the AsmDialect in theChad Rosier2012-09-051-7/+3
| | | | | | MachineInstr. llvm-svn: 163257
* [ms-inline asm] Propagate the asm dialect into the MachineInstr representation.Chad Rosier2012-09-051-0/+14
| | | | llvm-svn: 163243
* Typo.Jakob Stoklund Olesen2012-09-041-1/+1
| | | | llvm-svn: 163154
* Actually use the MachineOperand field for isRegTiedToDefOperand().Jakob Stoklund Olesen2012-09-041-103/+0
| | | | | | | | | | The MachineOperand::TiedTo field was maintained, but not used. This patch enables it in isRegTiedToDefOperand() and isRegTiedToUseOperand() which are the actual functions use by the register allocator. llvm-svn: 163153
* Allow tied uses and defs in different orders.Jakob Stoklund Olesen2012-09-041-30/+91
| | | | | | | | | | | | | | | | After much agonizing, use a full 4 bits of precious MachineOperand space to encode this. This uses existing padding, and doesn't grow MachineOperand beyond its current 32 bytes. This allows tied defs among the first 15 operands on a normal instruction, just like the current MCInstrDesc constraint encoding. Inline assembly needs to be able to tie more than the first 15 operands, and gets special treatment. Tied uses can appear beyond 15 operands, as long as they are tied to a def that's in range. llvm-svn: 163151
* Add MachineInstr::tieOperands, remove setIsTied().Jakob Stoklund Olesen2012-08-311-6/+16
| | | | | | | | | | | 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 use MCInstrDesc flags for implicit operands.Jakob Stoklund Olesen2012-08-301-11/+16
| | | | | | | | | | | | | When a MachineInstr is constructed, its implicit operands are added first, then the explicit operands are inserted before the implicits. MCInstrDesc has oprand flags like early clobber and operand ties that apply to the explicit operands. Don't look at those flags when the implicit operands are first added in the explicit operands's positions. llvm-svn: 162910
* Rename hasVolatileMemoryRef() to hasOrderedMemoryRef().Jakob Stoklund Olesen2012-08-291-8/+8
| | | | | | | | Ordered memory operations are more constrained than volatile loads and stores because they must be ordered with respect to all other memory operations. llvm-svn: 162861
* Don't move normal loads across volatile/atomic loads.Jakob Stoklund Olesen2012-08-291-3/+8
| | | | | | | | | | | | | It is technically allowed to move a normal load across a volatile load, but probably not a good idea. It is not allowed to move a load across an atomic load with Ordering > Monotonic, and we model those with MOVolatile as well. I recently removed the mayStore flag from atomic load instructions, so they don't need a pseudo-opcode. This patch makes up for the difference. llvm-svn: 162857
* Maintain a vaild isTied bit as operands are added and removed.Jakob Stoklund Olesen2012-08-291-1/+39
| | | | | | | | The isTied bit is set automatically when a tied use is added and MCInstrDesc indicates a tied operand. The tie is broken when one of the tied operands is removed. llvm-svn: 162814
* Add a MachineOperand::isTied() flag.Jakob Stoklund Olesen2012-08-281-21/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While in SSA form, a MachineInstr can have pairs of tied defs and uses. The tied operands are used to represent read-modify-write operands that must be assigned the same physical register. Previously, tied operand pairs were computed from fixed MCInstrDesc fields, or by using black magic on inline assembly instructions. The isTied flag makes it possible to add tied operands to any instruction while getting rid of (some of) the inlineasm magic. Tied operands on normal instructions are needed to represent predicated individual instructions in SSA form. An extra <tied,imp-use> operand is required to represent the output value when the instruction predicate is false. Adding a predicate to: %vreg0<def> = ADD %vreg1, %vreg2 Will look like: %vreg0<tied,def> = ADD %vreg1, %vreg2, pred:3, %vreg7<tied,imp-use> The virtual register %vreg7 is the value given to %vreg0 when the predicate is false. It will be assigned the same physreg as %vreg0. This commit adds the isTied flag and sets it based on MCInstrDesc when building an instruction. The flag is not used for anything yet. llvm-svn: 162774
* Don't allow TargetFlags on MO_Register MachineOperands.Jakob Stoklund Olesen2012-08-281-2/+2
| | | | | | | | | | | | Register operands are manipulated by a lot of target-independent code, and it is not always possible to preserve target flags. That means it is not safe to use target flags on register operands. None of the targets in the tree are using register operand target flags. External targets should be using immediate operands to annotate instructions with operand modifiers. llvm-svn: 162770
* Also update MRI use lists when changing a use to a def and vice versa.Jakob Stoklund Olesen2012-08-101-19/+38
| | | | | | This was the cause of the buildbot failures. llvm-svn: 161643
* Move use list management into MachineRegisterInfo.Jakob Stoklund Olesen2012-08-091-76/+31
| | | | | | | | | | | | | | Register MachineOperands are kept in linked lists accessible via MRI's reg_iterator interfaces. The linked list management was handled partly by MachineOperand methods, partly by MRI methods. Move all of the list management into MRI, delete MO::AddRegOperandToRegInfo() and MO::RemoveRegOperandFromRegInfo(). Be more explicit about handling the cases where an MRI pointer isn't available. llvm-svn: 161632
* Add a new kind of MachineOperand: MO_TargetIndex.Jakob Stoklund Olesen2012-08-071-0/+7
| | | | | | | | | | | | A target index operand looks a lot like a constant pool reference, but it is completely target-defined. It contains the 8-bit TargetFlags, a 32-bit index, and a 64-bit offset. It is preserved by all code generator passes. TargetIndex operands can be used to carry target-specific information in cases where immediate operands won't suffice. llvm-svn: 161441
* Finish fixing the MachineOperand hashing, providing a nice modernChandler Carruth2012-07-051-47/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | hash_value overload for MachineOperands. This addresses a FIXME sufficient for me to remove it, and cleans up the code nicely too. The important changes to the hashing logic: - TargetFlags are now included in all of the hashes. These were complete missed. - Register operands have their subregisters and whether they are a def included in the hash. - We now actually hash all of the operand types. Previously, many operand types were simply *dropped on the floor*. For example: - Floating point immediates - Large integer immediates (>64-bit) - External globals! - Register masks - Metadata operands - It removes the offset from the block-address hash; I'm a bit suspicious of this, but isIdenticalTo doesn't consider the offset for black addresses. Any patterns involving these entities could have triggered extreme slowdowns in MachineCSE or PHIElimination. Let me know if there are PRs you think might be closed now... I'm looking myself, but I may miss them. llvm-svn: 159743
OpenPOWER on IntegriCloud