summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/MachineInstr.cpp
Commit message (Collapse)AuthorAgeFilesLines
* MachineInstr: Print name for subreg index in SUBREG_TO_REGMatthias Braun2017-01-091-1/+2
| | | | | | | | SUBREG_TO_REG takes a subregister index as 3rd operand, print the name instead of a number. We already do the same for INSERT_SUBREG and REG_SEQUENCE. llvm-svn: 291481
* machine combiner: fix pretty printerSebastian Pop2016-12-211-7/+9
| | | | | | | | | | | we used to print UNKNOWN instructions when the instruction to be printer was not yet inserted in any BB: in that case the pretty printer would not be able to compute a TII as the instruction does not belong to any BB or function yet. This patch explicitly passes the TII to the pretty-printer. Differential Revision: https://reviews.llvm.org/D27645 llvm-svn: 290228
* [CodeGen] Make MachineInstr::isIdenticalTo() symmetric.Bjorn Pettersson2016-12-191-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: MachineInstr::isIdenticalTo() is for some reason not symmetric when comparing bundles, which gives us the property: I1->isIdenticalTo(*I2) != I2->isIdenticalTo(*I1) when comparing bundles where one bundle is longer than the other. This patch makes sure that bundles of different length always are considered as not being identical. Thus, the result of the comparison will be the same regardless of which side that happens to be to the left. Reviewers: dexonsmith, jonpa, andrew.w.kaylor Subscribers: llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D27508 llvm-svn: 290095
* Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann2016-12-141-1/+1
| | | | | | | | | | | | | At least the plugin used by the LibreOffice build (<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly uses those members (through inline functions in LLVM/Clang include files in turn using them), but they are not exported by utils/extract_symbols.py on Windows, and accessing data across DLL/EXE boundaries on Windows is generally problematic. Differential Revision: https://reviews.llvm.org/D26671 llvm-svn: 289647
* MachineOperand: Add dump() methodMatthias Braun2016-11-181-0/+6
| | | | llvm-svn: 287302
* [MachineMemOperand] Move synchronization scope and atomic orderings from ↵Konstantin Zhuravlyov2016-10-151-1/+11
| | | | | | | | SDNode to MachineMemOperand, and remove redundant getAtomic* member functions from SelectionDAG. Differential Revision: https://reviews.llvm.org/D24577 llvm-svn: 284312
* Fix formatting in findRegisterUseOperandIdx. NFC.Fraser Cormack2016-10-111-7/+5
| | | | llvm-svn: 283860
* AMDGPU: Support commuting a FrameIndex operandMatt Arsenault2016-09-131-0/+10
| | | | llvm-svn: 281369
* [GlobalISel] Fix mismatched "<..)" in intrinsic MO printing. NFC.Ahmed Bougacha2016-09-121-2/+2
| | | | llvm-svn: 281229
* [CodeGen] Split out the notions of MI invariance and MI dereferenceability.Justin Lebar2016-09-111-3/+4
| | | | | | | | | | | | | | | | | | | Summary: An IR load can be invariant, dereferenceable, neither, or both. But currently, MI's notion of invariance is IR-invariant && IR-dereferenceable. This patch splits up the notions of invariance and dereferenceability at the MI level. It's NFC, so adds some probably-unnecessary "is-dereferenceable" checks, which we can remove later if desired. Reviewers: chandlerc, tstellarAMD Subscribers: jholewinski, arsenm, nemanjai, llvm-commits Differential Revision: https://reviews.llvm.org/D23371 llvm-svn: 281151
* [CodeGen] Rename MachineInstr::isInvariantLoad to ↵Justin Lebar2016-09-101-7/+5
| | | | | | | | | | | | | | | | | | | | isDereferenceableInvariantLoad. NFC Summary: I want to separate out the notions of invariance and dereferenceability at the MI level, so that they correspond to the equivalent concepts at the IR level. (Currently an MI load is MI-invariant iff it's IR-invariant and IR-dereferenceable.) First step is renaming this function. Reviewers: chandlerc Subscribers: MatzeB, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D23370 llvm-svn: 281125
* GlobalISel: move type information to MachineRegisterInfo.Tim Northover2016-09-091-56/+5
| | | | | | | | | | | | | | | | | We want each register to have a canonical type, which means the best place to store this is in MachineRegisterInfo rather than on every MachineInstr that happens to use or define that register. Most changes following from this are pretty simple (you need an MRI anyway if you're going to be doing any transformations, so just check the type there). But legalization doesn't really want to check redundant operands (when, for example, a G_ADD only ever has one type) so I've made use of MCInstrDesc's operand type field to encode these constraints and limit legalization's work. As an added bonus, more validation is possible, both in MachineVerifier and MachineIRBuilder (coming soon). llvm-svn: 281035
* Fix some more asserts after r279466.Pete Cooper2016-08-231-1/+1
| | | | | | | | | | | | | | | | That commit added a new version of Intrinsic::getName which should only be called when the intrinsic has no overloaded types. There are several debugging paths, such as SDNode::dump which are printing the name of the intrinsic but don't have the overloaded types. These paths should be ok to just print the name instead of crashing. The fix here is ultimately to just add a 'None' second argument as that calls the overload capable getName, which is less efficient, but this is a debugging path anyway, and not perf critical. Thanks to Björn Pettersson for pointing out that there were more crashes. llvm-svn: 279528
* Reset isUndef when removing subreg from a def operandKrzysztof Parzyszek2016-08-221-0/+2
| | | | llvm-svn: 279437
* GlobalISel: support irtranslation of icmp instructions.Tim Northover2016-08-171-1/+9
| | | | llvm-svn: 278969
* Use range algorithms instead of unpacking begin/endDavid Majnemer2016-08-111-2/+2
| | | | | | No functionality change is intended. llvm-svn: 278417
* CodeGen: add new "intrinsic" MachineOperand kind.Tim Northover2016-07-291-5/+25
| | | | | | | This will be used during GlobalISel, where we need a more robust and readable way to write tests than a simple immediate ID. llvm-svn: 277209
* MachineFunction: Return reference for getFrameInfo(); NFCMatthias Braun2016-07-281-2/+2
| | | | | | | getFrameInfo() never returns nullptr so we should use a reference instead of a pointer. llvm-svn: 277017
* [GlobalISel] Remove types on selected insts instead of using LLT().Ahmed Bougacha2016-07-281-0/+6
| | | | | | | | | | LLT() has a particular meaning: it's one invalid type. But we really want selected instructions to have no type whatsoever. Also verify that types don't linger after ISel, and enable the verifier on the AArch64 select test. llvm-svn: 277001
* GlobalISel: allow multiple types on MachineInstrs.Tim Northover2016-07-221-11/+21
| | | | llvm-svn: 276481
* GlobalISel: implement low-level type with just size & vector lanes.Tim Northover2016-07-201-9/+9
| | | | | | | | This should be all the low-level instruction selection needs to determine how to implement an operation, with the remaining context taken from the opcode (e.g. G_ADD vs G_FADD) or other flags not based on type (e.g. fast-math). llvm-svn: 276158
* [inlineasm] Propagate operand constraints to the backendSimon Dardis2016-07-181-2/+33
| | | | | | | | | | | | | | | | | | | | | | | | When SelectionDAGISel transforms a node representing an inline asm block, memory constraint information is not preserved. This can cause constraints to be broken when a memory offset is of the form: offset + frame index when the frame is resolved. By propagating the constraints all the way to the backend, targets can enforce memory operands of inline assembly to conform to their constraints. For MIPSR6, some instructions had their offsets reduced to 9 bits from 16 bits such as ll/sc. This becomes problematic when using inline assembly to perform atomic operations, as an offset can generated that is too big to encode in the instruction. Reviewers: dsanders, vkalintris Differential Review: https://reviews.llvm.org/D21615 llvm-svn: 275786
* [CodeGen] Refactor MachineMemOperand::Flags's target-specific flags.Justin Lebar2016-07-141-2/+0
| | | | | | | | | | | | | | | | | Summary: Make the target-specific flags in MachineMemOperand::Flags real, bona fide enum values. This simplifies users, prevents various constants from going out of sync, and avoids the false sense of security provided by declaring static members in classes and then forgetting to define them inside of cpp files. Reviewers: MatzeB Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D22372 llvm-svn: 275451
* [CodeGen] Refactor MachineMemOperand's Flags enum.Justin Lebar2016-07-141-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | Summary: - Give it a shorter name (because we're going to refer to it often from SelectionDAG and friends). - Split the flags and alignment into separate variables. - Specialize FlagsEnumTraits for it, so we can do bitwise ops on it without losing type information. - Make some enum values constants in MachineMemOperand instead. MOMaxBits should not be a valid Flag. - Simplify some of the bitwise ops for dealing with Flags. Reviewers: chandlerc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D22281 llvm-svn: 275438
* [MI] Clean up some loops over MachineInstr::memoperands(). NFCJustin Lebar2016-07-131-14/+11
| | | | | | | Use range-based for loops and llvm::any_of instead of explicit iterators. llvm-svn: 275332
* [MI] Fix MachineInstr::isInvariantLoad.Justin Lebar2016-07-131-2/+1
| | | | | | | | | | | | | | | | | | | | Summary: Previously it would say we had an invariant load if any of the memory operands were invariant. But the load should be invariant only if *all* the memory operands are invariant. No testcase because this has proven to be very difficult to tickle in practice. As just one example, ARM's ldrd instruction, which loads 64 bits into two 32-bit regs, is theoretically affected by this. But when it's produced, it loses its memoperands' invariance bits! Reviewers: jfb Subscribers: llvm-commits, aemerson Differential Revision: http://reviews.llvm.org/D22318 llvm-svn: 275331
* AMDGPU: Add convergent flag to INLINEASM instruction.Wei Ding2016-06-221-0/+2
| | | | | | Differential Revision: http://reviews.llvm.org/D21214 llvm-svn: 273455
* Pass DebugLoc and SDLoc by const ref.Benjamin Kramer2016-06-121-5/+6
| | | | | | | | This used to be free, copying and moving DebugLocs became expensive after the metadata rewrite. Passing by reference eliminates a ton of track/untrack operations. No functionality change intended. llvm-svn: 272512
* Fix PR26655: Bail out if all regs of an inst BUNDLE have the correct kill flagMandeep Singh Grang2016-05-101-0/+7
| | | | | | | | | | | | | | | | | | | | Summary: While setting kill flags on instructions inside a BUNDLE, we bail out as soon as we set kill flag on a register. But we are missing a check when all the registers already have the correct kill flag set. We need to bail out in that case as well. This patch refactors the old code and simply makes use of the addRegisterKilled function in MachineInstr.cpp in order to determine whether to set/remove kill on an instruction. Reviewers: apazos, t.p.northover, pete, MatzeB Subscribers: MatzeB, davide, llvm-commits Differential Revision: http://reviews.llvm.org/D17356 llvm-svn: 269092
* AMDGPU/SI: add llvm.amdgcn.ps.live intrinsicNicolai Haehnle2016-04-221-0/+11
| | | | | | | | | | | | | | | | | | | | | | | Summary: This intrinsic returns true if the current thread belongs to a live pixel and false if it belongs to a pixel that we are executing only for derivative computation. It will be used by Mesa to implement gl_HelperInvocation. Note that for pixels that are killed during the shader, this implementation also returns true, but it doesn't matter because those pixels are always disabled in the EXEC mask. This unearthed a corner case in the instruction verifier, which complained about a v_cndmask 0, 1, exec, exec<imp-use> instruction. That's stupid but correct code, so make the verifier accept it as such. Reviewers: arsenm, tstellarAMD Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D19191 llvm-svn: 267102
* Sink DI metadata usage out of MachineInstr.h and MachineInstrBuilder.hReid Kleckner2016-04-141-0/+49
| | | | | | | | | | | MachineInstr.h and MachineInstrBuilder.h are very popular headers, widely included across all LLVM backends. It turns out that there only a handful of TUs that actually care about DI operands on MachineInstrs. After this change, touching DebugInfoMetadata.h and rebuilding llc only needs 112 actions instead of 542. llvm-svn: 266351
* [MachineInstr] Teach the print method about RegisterBank.Quentin Colombet2016-04-071-11/+10
| | | | | | | | Properly print either the register class or the register bank or a virtual register. Get rid of a few ifdefs in the process. llvm-svn: 265745
* Revert "NFC: static_assert instead of comment"JF Bastien2016-03-261-3/+1
| | | | | | | | | | | This reverts commit fa36fcff16c7d4f78204d6296bf96c3558a4a672. Causes the following Windows failure: C:\Buildbot\Slave\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\lib\CodeGen\MachineInstr.cpp(762): error C2338: must be trivially copyable to memmove llvm-svn: 264516
* NFC: static_assert instead of commentJF Bastien2016-03-261-1/+3
| | | | | | | | | | Summary: isPodLike is as close as we have for is_trivially_copyable. Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18483 llvm-svn: 264515
* [MachineInstr] Get rid of some GlobalISel ifdefs.Quentin Colombet2016-03-071-5/+24
| | | | | | | | Now the type API is always available, but when global-isel is not built the implementation does nothing. Note: The implementation free of ifdefs is WIP and tracked here in PR26576. llvm-svn: 262873
* CodeGen: Change MachineInstr to use MachineInstr&, NFCDuncan P. N. Exon Smith2016-02-271-12/+12
| | | | | | | | Change MachineInstr API to prefer MachineInstr& over MachineInstr* whenever the parameter is expected to be non-null. Slowly inching toward being able to fix PR26753. llvm-svn: 262149
* WIP: CodeGen: Use MachineInstr& in MachineInstrBundle.h, NFCDuncan P. N. Exon Smith2016-02-271-1/+1
| | | | | | | | Update APIs in MachineInstrBundle.h to take and return MachineInstr& instead of MachineInstr* when the instruction cannot be null. Besides being a nice cleanup, this is tacking toward a fix for PR26753. llvm-svn: 262141
* Minor code cleanups. NFC.Junmo Park2016-02-261-3/+3
| | | | llvm-svn: 261955
* MachineInstr: Respect register aliases in clearRegiserKills()Matthias Braun2016-02-241-1/+1
| | | | | | | | | | | | | | | This fixes bugs in copy elimination code in llvm. It slightly changes the semantics of clearRegisterKills(). This is appropriate because: - Users in lib/CodeGen/MachineCopyPropagation.cpp and lib/Target/AArch64RedundantCopyElimination.cpp and lib/Target/SystemZ/SystemZElimCompare.cpp are incorrect without it (see included testcase). - All other users in llvm are unaffected (they pass TRI==nullptr) - (Kill flags are optional anyway so removing too many shouldn't hurt.) Differential Revision: http://reviews.llvm.org/D17554 llvm-svn: 261763
* Revert "CodeGen: MachineInstr::getIterator() => getInstrIterator(), NFC"Duncan P. N. Exon Smith2016-02-221-10/+14
| | | | | | | | | | This reverts commit r261504, since it's not obvious the new name is better: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160222/334298.html I'll recommit if we get consensus that it's the right direction. llvm-svn: 261567
* CodeGen: MachineInstr::getIterator() => getInstrIterator(), NFCDuncan P. N. Exon Smith2016-02-211-14/+10
| | | | | | | | | | | | | | | | | | | | | | | Delete MachineInstr::getIterator(), since the term "iterator" is overloaded when talking about MachineInstr. - Downcast to ilist_node in iplist::getNextNode() and getPrevNode() so that ilist_node::getIterator() is still available. - Add it back as MachineInstr::getInstrIterator(). This matches the naming in MachineBasicBlock. - Add MachineInstr::getBundleIterator(). This is explicitly called "bundle" (not matching MachineBasicBlock) to disintinguish it clearly from ilist_node::getIterator(). - Update all calls. Some of these I switched to `auto` to remove boiler-plate, since the new name is clear about the type. There was one call I updated that looked fishy, but it wasn't clear what the right answer was. This was in X86FrameLowering::inlineStackProbe(), added in r252578 in lib/Target/X86/X86FrameLowering.cpp. I opted to leave the behaviour unchanged, but I'll reply to the original commit on the list in a moment. llvm-svn: 261504
* Remove uses of builtin comma operator.Richard Trieu2016-02-181-2/+4
| | | | | | Cleanup for upcoming Clang warning -Wcomma. No functionality change intended. llvm-svn: 261270
* [GlobalISel] Add a type to MachineInstr.Quentin Colombet2016-02-111-5/+20
| | | | | | | | | | | | | | | | | | | | | | | | We actually need that information only for generic instructions, therefore it would be nice not to have to pay the extra memory consumption for all instructions. Especially because a typed non-generic instruction does not make sense. The question is then, is it possible to have that information in a union or something? My initial thought was that we could have a derived class GenericMachineInstr with additional information, but in practice it makes little to no sense since generic MachineInstrs are likely turned into non-generic ones by just switching the opcode. In other words, we don't want to go through the process of creating a new, non-generic MachineInstr, object each time we do this switch. The memory benefit probably is not worth the extra compile time. Another option would be to keep the type of the MachineInstr in a side table. This would induce an extra indirection though. Anyway, I will file a PR to discuss about it and remember we need to come back to it at some point. llvm-svn: 260558
* [GlobalISel][MachineRegisterInfo] Add a method to create generic vregs.Quentin Colombet2016-02-111-0/+5
| | | | | | | | | | | | | | | | For now, generic virtual registers will not have a register class. We may want to change that. For instance, if we want to use all the methods from TargetRegisterInfo with generic virtual registers, we need to either have some sort of generic register classes that do what we want, or teach those methods how to deal with nullptr register class. Although the latter seems easy enough to do, we may still want to differenciate generic register classes from nullptr to catch cases where nullptr gets introduced by a bug of some sort. Anyway, I will file a PR to keep track of that. llvm-svn: 260474
* [GlobalISel] Remember the size of generic virtual registersQuentin Colombet2016-02-101-1/+8
| | | | llvm-svn: 260468
* Fix printing of f16 machine operandsMatt Arsenault2016-02-051-2/+8
| | | | | | | | | | | | | Only single and double FP immediates are correctly printed by MachineInstr::print() during debug output. Half float type goes to APFloat::convertToDouble() and hits assertion it is not a double semantics. This diff prints half machine operands correctly. This cannot currently be hit by any in-tree target. Patch by Stanislav Mekhanoshin llvm-svn: 259857
* Annotate dump() methods with LLVM_DUMP_METHOD, addressing Richard Smith ↵Yaron Keren2016-01-291-1/+1
| | | | | | | | r259192 post commit comment. clang part in r259232, this is the LLVM part of the patch. llvm-svn: 259240
* Consolidate MemRefs handling from BranchFolding and correct latent bugPhilip Reames2016-01-061-4/+34
| | | | | | | | | | | | Move the logic from BranchFolding to use the shared infrastructure for merging MMOs introduced in 256909. This has the effect of making BranchFolding more capable. In the process, fix a latent bug. The existing handling for merging didn't handle the case where one of the instructions being merged had overflowed and dropped MemRefs. This was a latent bug in the places the code was commoned from, but potentially reachable in BranchFolding. Once this is in, we're left with a single place to consider implementing MMO unique-ing as proposed in http://reviews.llvm.org/D15230. Differential Revision: http://reviews.llvm.org/D15913 llvm-svn: 256966
* Fix a warning [NFC]Philip Reames2016-01-061-1/+2
| | | | llvm-svn: 256916
* Extract helper function to merge MemoryOperand lists [NFC]Philip Reames2016-01-061-0/+20
| | | | | | | | | | In the discussion on http://reviews.llvm.org/D15730, Andy pointed out we had a utility function for merging MMO lists. Since it turned we actually had two copies and there's another review in progress (http://reviews.llvm.org/D15230) which needs the same, extract it into a utility function and clean up the interfaces to make it easier to use with a MachineInstBuilder. I introduced a pair here to track size and allocation together. I think we should probably move in the direction of the MachineOperandsRef helper class, but I'm leaving that for further work. I want to get the poison state introduced before I make major changes to the interface. Differential Revision: http://reviews.llvm.org/D15757 llvm-svn: 256909
OpenPOWER on IntegriCloud