summaryrefslogtreecommitdiff
path: root/lib/CodeGen/MachineInstr.cpp
Commit message (Collapse)AuthorAge
* Remove liveout lists from MachineRegisterInfo.Jakob Stoklund Olesen2013-02-05
| | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174417 91177308-0d34-0410-b5e6-96231b3b80d8
* ScheduleDAG: colorize the DOT graph and improve formatting.Andrew Trick2013-01-25
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173431 91177308-0d34-0410-b5e6-96231b3b80d8
* For inline asm:Eric Christopher2013-01-11
| | | | | | | | | | | - recognize string "{memory}" in the MI generation - mark as mayload/maystore when there's a memory clobber constraint. PR14859. Patch by Krzysztof Parzyszek git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172228 91177308-0d34-0410-b5e6-96231b3b80d8
* Allow hasProperty() to be called on bundle-internal instructions.Jakob Stoklund Olesen2013-01-10
| | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172082 91177308-0d34-0410-b5e6-96231b3b80d8
* Support headerless bundles in MachineInstr::hasProperty().Jakob Stoklund Olesen2013-01-10
| | | | | | This function can still work without a BUNDLE header instruction. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172029 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't print bundle flags.Jakob Stoklund Olesen2013-01-09
| | | | | | | The bundle flags are used by MachineBasicBlock::print(), they don't need to clutter up individual MachineInstrs. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171986 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't require BUNDLE headers in MachineInstr::getBundleSize().Jakob Stoklund Olesen2013-01-09
| | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171985 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix a typo in MachineInstr::unbundleFromSucc() method.Sergei Larin2013-01-09
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171983 91177308-0d34-0410-b5e6-96231b3b80d8
* Pack MachineOperand bitfields better.Jakob Stoklund Olesen2013-01-07
| | | | | | Previously, 4 bits were unused. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171814 91177308-0d34-0410-b5e6-96231b3b80d8
* Pack MachineInstr fields better.Jakob Stoklund Olesen2013-01-07
| | | | | | This shrinks MachineInstr to 64 bytes (from 72). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171813 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't call destructors on MachineInstr and MachineOperand.Jakob Stoklund Olesen2013-01-05
| | | | | | | | | | | | | | | | | | | | 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(). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171599 91177308-0d34-0410-b5e6-96231b3b80d8
* Use ArrayRecycler for MachineInstr operand lists.Jakob Stoklund Olesen2013-01-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171598 91177308-0d34-0410-b5e6-96231b3b80d8
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-02
| | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove a special case that doesn't seem necessary any longer.Jakob Stoklund Olesen2012-12-22
| | | | | | | Back when this exception was added, it was skipping a lot more code, but now it just looks like a premature optimization. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170989 91177308-0d34-0410-b5e6-96231b3b80d8
* Use getNumOperands() instead of Operands.size().Jakob Stoklund Olesen2012-12-22
| | | | | | | The representation of the Operands array is going to change soon so it can be allocated from a BumpPtrAllocator. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170988 91177308-0d34-0410-b5e6-96231b3b80d8
* Require the two-argument MI::addOperand(MF, MO) for dangling instructions.Jakob Stoklund Olesen2012-12-20
| | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170798 91177308-0d34-0410-b5e6-96231b3b80d8
* Add an MF argument to MI::copyImplicitOps().Jakob Stoklund Olesen2012-12-20
| | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170797 91177308-0d34-0410-b5e6-96231b3b80d8
* Use two-arg addOperand(MF, MO) internally in MachineInstr when possible.Jakob Stoklund Olesen2012-12-20
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170796 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove two dead functions.Jakob Stoklund Olesen2012-12-20
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170766 91177308-0d34-0410-b5e6-96231b3b80d8
* Use bidirectional bundle flags to simplify important functions.Jakob Stoklund Olesen2012-12-18
| | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170473 91177308-0d34-0410-b5e6-96231b3b80d8
* Verify bundle flag consistency when setting them.Jakob Stoklund Olesen2012-12-18
| | | | | | | Now that the bundle flag aware APIs are all in place, it is possible to continuously verify the flag consistency. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170465 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't allow the automatically updated MI flags to be set directly.Jakob Stoklund Olesen2012-12-18
| | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170459 91177308-0d34-0410-b5e6-96231b3b80d8
* Tighten up the erase/remove API for bundled instructions.Jakob Stoklund Olesen2012-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170384 91177308-0d34-0410-b5e6-96231b3b80d8
* Add higher-level API for dealing with bundled MachineInstrs.Jakob Stoklund Olesen2012-12-07
| | | | | | | | | | | | | | | | | | | | | 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(). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169583 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove unused MachineInstr constructors.Jakob Stoklund Olesen2012-12-05
| | | | | | | | A MachineInstr can only ever be constructed by CreateMachineInstr() and CloneMachineInstr(), and those factories don't use the removed constructors. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169395 91177308-0d34-0410-b5e6-96231b3b80d8
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-03
| | | | | | | | | | | | | | | | | 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. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8
* Check that iterator I is not the end iterator.Akira Hatanaka2012-10-31
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167086 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove unused MachineInstr constructors that don't take a DebugLoc argument.Craig Topper2012-10-07
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165382 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix PR11985Michael Liao2012-09-12
| | | | | | | | | | | | | - 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163743 91177308-0d34-0410-b5e6-96231b3b80d8
* Release build: guard dump functions withManman Ren2012-09-11
| | | | | | | | | "#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)" No functional change. Update r163339. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163653 91177308-0d34-0410-b5e6-96231b3b80d8
* Release build: guard dump functions with "ifndef NDEBUG"Manman Ren2012-09-06
| | | | | | | No functional change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163339 91177308-0d34-0410-b5e6-96231b3b80d8
* Cleanup a few magic numbers.Chad Rosier2012-09-05
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163263 91177308-0d34-0410-b5e6-96231b3b80d8
* [ms-inline asm] We only need one bit to represent the AsmDialect in theChad Rosier2012-09-05
| | | | | | | MachineInstr. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163257 91177308-0d34-0410-b5e6-96231b3b80d8
* [ms-inline asm] Propagate the asm dialect into the MachineInstr representation.Chad Rosier2012-09-05
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163243 91177308-0d34-0410-b5e6-96231b3b80d8
* Typo.Jakob Stoklund Olesen2012-09-04
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163154 91177308-0d34-0410-b5e6-96231b3b80d8
* Actually use the MachineOperand field for isRegTiedToDefOperand().Jakob Stoklund Olesen2012-09-04
| | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163153 91177308-0d34-0410-b5e6-96231b3b80d8
* Allow tied uses and defs in different orders.Jakob Stoklund Olesen2012-09-04
| | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163151 91177308-0d34-0410-b5e6-96231b3b80d8
* Add MachineInstr::tieOperands, remove setIsTied().Jakob Stoklund Olesen2012-08-31
| | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163021 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't use MCInstrDesc flags for implicit operands.Jakob Stoklund Olesen2012-08-30
| | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162910 91177308-0d34-0410-b5e6-96231b3b80d8
* Rename hasVolatileMemoryRef() to hasOrderedMemoryRef().Jakob Stoklund Olesen2012-08-29
| | | | | | | | Ordered memory operations are more constrained than volatile loads and stores because they must be ordered with respect to all other memory operations. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162861 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't move normal loads across volatile/atomic loads.Jakob Stoklund Olesen2012-08-29
| | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162857 91177308-0d34-0410-b5e6-96231b3b80d8
* Maintain a vaild isTied bit as operands are added and removed.Jakob Stoklund Olesen2012-08-29
| | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162814 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a MachineOperand::isTied() flag.Jakob Stoklund Olesen2012-08-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162774 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't allow TargetFlags on MO_Register MachineOperands.Jakob Stoklund Olesen2012-08-28
| | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162770 91177308-0d34-0410-b5e6-96231b3b80d8
* Also update MRI use lists when changing a use to a def and vice versa.Jakob Stoklund Olesen2012-08-10
| | | | | | This was the cause of the buildbot failures. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161643 91177308-0d34-0410-b5e6-96231b3b80d8
* Move use list management into MachineRegisterInfo.Jakob Stoklund Olesen2012-08-09
| | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161632 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a new kind of MachineOperand: MO_TargetIndex.Jakob Stoklund Olesen2012-08-07
| | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161441 91177308-0d34-0410-b5e6-96231b3b80d8
* Finish fixing the MachineOperand hashing, providing a nice modernChandler Carruth2012-07-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159743 91177308-0d34-0410-b5e6-96231b3b80d8
* The hash function for MI expressions, used by MachineCSE, is reallyChandler Carruth2012-07-05
| | | | | | | | | | | | | | | | | | | | | broken. This patch fixes the superficial problems which lead to the intractably slow compile times reported in PR13225. The specific issue is that we were failing to include the *offset* of a global variable in the hash code. Oops. This would in turn cause all MIs which were only distinguishable due to operating on different offsets of a global variable to produce identical hash functions. In some of the test cases attached to the PR I saw hash table activity where there were O(1000) probes-per-lookup *on average*. A very few entries were responsible for most of these probes. There is still quite a bit more to do here. The ad-hoc layering of data in MachineOperands makes them *extremely* brittle to hash correctly. We're missing quite a few other cases, the only ones I've fixed here are the specific MO types which were allowed through the assert() in getOffset(). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159741 91177308-0d34-0410-b5e6-96231b3b80d8
* Allow trailing physreg RegisterSDNode operands on non-variadic instructions.Jakob Stoklund Olesen2012-07-04
| | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159727 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-18 06:36:48 +0000