summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/MachineInstr.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [CodeGen] Cleanup MachineOperandFrancis Visoiu Mistrih2017-11-281-24/+0
| | | | | | | | * clang-format * move doxygen from the implementation to headers * remove duplicate doxygen llvm-svn: 319193
* [CodeGen] Rename functions PrintReg* to printReg*Francis Visoiu Mistrih2017-11-281-4/+4
| | | | | | | | | | | LLVM Coding Standards: Function names should be verb phrases (as they represent actions), and command-like function should be imperative. The name should be camel case, and start with a lower case letter (e.g. openFile() or isFoo()). Differential Revision: https://reviews.llvm.org/D40416 llvm-svn: 319168
* Fix a bunch more layering of CodeGen headers that are in TargetDavid Blaikie2017-11-171-2/+2
| | | | | | | | All these headers already depend on CodeGen headers so moving them into CodeGen fixes the layering (since CodeGen depends on Target, not the other way around). llvm-svn: 318490
* MI: Print ranges on MMOMatt Arsenault2017-11-131-0/+15
| | | | llvm-svn: 318020
* Revert "Correct dwarf unwind information in function epilogue for X86"Reid Kleckner2017-11-081-46/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts r317579, originally committed as r317100. There is a design issue with marking CFI instructions duplicatable. Not all targets support the CFIInstrInserter pass, and targets like Darwin can't cope with duplicated prologue setup CFI instructions. The compact unwind info emission fails. When the following code is compiled for arm64 on Mac at -O3, the CFI instructions end up getting tail duplicated, which causes compact unwind info emission to fail: int a, c, d, e, f, g, h, i, j, k, l, m; void n(int o, int *b) { if (g) f = 0; for (; f < o; f++) { m = a; if (l > j * k > i) j = i = k = d; h = b[c] - e; } } We get assembly that looks like this: ; BB#1: ; %if.then Lloh3: adrp x9, _f@GOTPAGE Lloh4: ldr x9, [x9, _f@GOTPAGEOFF] mov w8, wzr Lloh5: str wzr, [x9] stp x20, x19, [sp, #-16]! ; 8-byte Folded Spill .cfi_def_cfa_offset 16 .cfi_offset w19, -8 .cfi_offset w20, -16 cmp w8, w0 b.lt LBB0_3 b LBB0_7 LBB0_2: ; %entry.if.end_crit_edge Lloh6: adrp x8, _f@GOTPAGE Lloh7: ldr x8, [x8, _f@GOTPAGEOFF] Lloh8: ldr w8, [x8] stp x20, x19, [sp, #-16]! ; 8-byte Folded Spill .cfi_def_cfa_offset 16 .cfi_offset w19, -8 .cfi_offset w20, -16 cmp w8, w0 b.ge LBB0_7 LBB0_3: ; %for.body.lr.ph Note the multiple .cfi_def* directives. Compact unwind info emission can't handle that. llvm-svn: 317726
* Set hasSideEffects=0 for PHI and fix affected passesAlex Bradbury2017-11-081-1/+1
| | | | | | | | | | | | | | Previously, hasSideEffects was ? for TargetOpcode::PHI and would be inferred as 1. D37065 sets the previously inferred properties explicitly. This patch sets hasSideEffects=0 for PHI, as it is for G_PHI. MachineInstr::isSafeToMove has been updated so it still returns false for PHI. Additionally, HexagonBitSimplify relied on a PHI node having the hasUnmodeledSideEffects property. This patch fixes that assumption. Differential Revision: https://reviews.llvm.org/D37097 llvm-svn: 317721
* Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layeringDavid Blaikie2017-11-081-1/+1
| | | | | | | | This header includes CodeGen headers, and is not, itself, included by any Target headers, so move it into CodeGen to match the layering of its implementation. llvm-svn: 317647
* Reland "Correct dwarf unwind information in function epilogue for X86"Petar Jovanovic2017-11-071-4/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reland r317100 with minor fix regarding ComputeCommonTailLength function in BranchFolding.cpp. Skipping top CFI instructions block needs to executed on several more return points in ComputeCommonTailLength(). Original r317100 message: "Correct dwarf unwind information in function epilogue for X86" This patch aims to provide correct dwarf unwind information in function epilogue for X86. It consists of two parts. The first part inserts CFI instructions that set appropriate cfa offset and cfa register in emitEpilogue() in X86FrameLowering. This part is X86 specific. The second part is platform independent and ensures that: - CFI instructions do not affect code generation - Unwind information remains correct when a function is modified by different passes. This is done in a late pass by analyzing information about cfa offset and cfa register in BBs and inserting additional CFI directives where necessary. Changed CFI instructions so that they: - are duplicable - are not counted as instructions when tail duplicating or tail merging - can be compared as equal Added CFIInstrInserter pass: - analyzes each basic block to determine cfa offset and register valid at its entry and exit - verifies that outgoing cfa offset and register of predecessor blocks match incoming values of their successors - inserts additional CFI directives at basic block beginning to correct the rule for calculating CFA Having CFI instructions in function epilogue can cause incorrect CFA calculation rule for some basic blocks. This can happen if, due to basic block reordering, or the existence of multiple epilogue blocks, some of the blocks have wrong cfa offset and register values set by the epilogue block above them. CFIInstrInserter is currently run only on X86, but can be used by any target that implements support for adding CFI instructions in epilogue. Patch by Violeta Vukobrat. llvm-svn: 317579
* Revert "Correct dwarf unwind information in function epilogue for X86"Petar Jovanovic2017-11-011-46/+4
| | | | | | | This reverts r317100 as it introduced sanitizer-x86_64-linux-autoconf buildbot failure (build #15606). llvm-svn: 317136
* Correct dwarf unwind information in function epilogue for X86Petar Jovanovic2017-11-011-4/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch aims to provide correct dwarf unwind information in function epilogue for X86. It consists of two parts. The first part inserts CFI instructions that set appropriate cfa offset and cfa register in emitEpilogue() in X86FrameLowering. This part is X86 specific. The second part is platform independent and ensures that: - CFI instructions do not affect code generation - Unwind information remains correct when a function is modified by different passes. This is done in a late pass by analyzing information about cfa offset and cfa register in BBs and inserting additional CFI directives where necessary. Changed CFI instructions so that they: - are duplicable - are not counted as instructions when tail duplicating or tail merging - can be compared as equal Added CFIInstrInserter pass: - analyzes each basic block to determine cfa offset and register valid at its entry and exit - verifies that outgoing cfa offset and register of predecessor blocks match incoming values of their successors - inserts additional CFI directives at basic block beginning to correct the rule for calculating CFA Having CFI instructions in function epilogue can cause incorrect CFA calculation rule for some basic blocks. This can happen if, due to basic block reordering, or the existence of multiple epilogue blocks, some of the blocks have wrong cfa offset and register values set by the epilogue block above them. CFIInstrInserter is currently run only on X86, but can be used by any target that implements support for adding CFI instructions in epilogue. Patch by Violeta Vukobrat. Differential Revision: https://reviews.llvm.org/D35844 llvm-svn: 317100
* Reverting r315590; it did not include changes for llvm-tblgen, which is ↵Aaron Ballman2017-10-151-2/+2
| | | | | | | | causing link errors for several people. Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::MatchableInfo::dump(void)const " (?dump@MatchableInfo@?A0xf4f1c304@@QEBAXXZ) referenced in function "public: void __cdecl `anonymous namespace'::AsmMatcherEmitter::run(class llvm::raw_ostream &)" (?run@AsmMatcherEmitter@?A0xf4f1c304@@QEAAXAEAVraw_ostream@llvm@@@Z) llvm-tblgen D:\llvm\2017\utils\TableGen\AsmMatcherEmitter.obj 1 llvm-svn: 315854
* [dump] Remove NDEBUG from test to enable dump methods [NFC]Don Hinton2017-10-121-2/+2
| | | | | | | | | | | | | | | Summary: Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP. Remove NDEBUG and only use LLVM_ENABLE_DUMP to enable dump methods. Move definition of LLVM_ENABLE_DUMP from config.h to llvm-config.h so it'll be picked up by public headers. Differential Revision: https://reviews.llvm.org/D38406 llvm-svn: 315590
* MachineInstr: Make isEqual agree with getHashValue in ↵Diana Picus2017-10-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MachineInstrExpressionTrait MachineInstr::isIdenticalTo has a lot of logic for dealing with register Defs (i.e. deciding whether to take them into account or ignore them). This logic gets things wrong in some obscure cases, for instance if an operand is not a Def for both the current MI and the one we are comparing to. I'm not sure if it's possible for this to happen for regular register operands, but it may happen in the ARM backend for special operands which use sentinel values for the register (i.e. 0, which is neither a physical register nor a virtual one). This causes MachineInstrExpressionTrait::isEqual (which uses MachineInstr::isIdenticalTo) to return true for the following instructions, which are the same except for the fact that one sets the flags and the other one doesn't: %1114 = ADDrsi %1113, %216, 17, 14, _, def _ %1115 = ADDrsi %1113, %216, 17, 14, _, _ OTOH, MachineInstrExpressionTrait::getHashValue returns different values for the 2 instructions due to the different isDef on the last operand. In practice this means that when trying to add those instructions to a DenseMap, they will be considered different because of their different hash values, but when growing the map we might get an assertion while copying from the old buckets to the new buckets because isEqual misleadingly returns true. This patch makes sure that isEqual and getHashValue agree, by improving the checks in MachineInstr::isIdenticalTo when we are ignoring virtual register definitions (which is what the Trait uses). Firstly, instead of checking isPhysicalRegister, we use !isVirtualRegister, so that we cover both physical registers and sentinel values. Secondly, instead of checking MachineOperand::isReg, we use MachineOperand::isIdenticalTo, which checks isReg, isSubReg and isDef, which are the same values that the hash function uses to compute the hash. Note that the function is symmetric with this change, since if the current operand is not a Def, we check MachineOperand::isIdenticalTo, which returns false if the operands have different isDef's. Differential Revision: https://reviews.llvm.org/D38789 llvm-svn: 315579
* CodeGen: Minor cleanups to use MachineInstr::getMF. NFCJustin Bogner2017-10-101-5/+5
| | | | | | | Since r315388 we have a shorter way to say this, so we'll replace MI->getParent()->getParent() with MI->getMF() in a few places. llvm-svn: 315390
* CodeGen: Add MachineInstr::getMF(). NFCJustin Bogner2017-10-101-0/+4
| | | | | | | | Similarly to how Instruction has getFunction, this adds a less verbose way to write MI->getParent()->getParent(). I'll follow up shortly with a change that changes a bunch of the uses. llvm-svn: 315388
* [DebugInfo] Add missing DW_OP_deref when an NRVO pointer is spilledReid Kleckner2017-09-151-15/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fixes PR34513. Indirect DBG_VALUEs typically come from dbg.declares of non-trivially copyable C++ objects that must be passed by address. We were already handling the case where the virtual register gets allocated to a physical register and is later spilled. That's what usually happens for normal parameters that aren't NRVO variables: they usually appear in physical register parameters, and are spilled later in the function, which would correctly add deref. NRVO variables are different because the dbg.declare can come much later after earlier instructions cause the incoming virtual register to be spilled. Also, clean up this code. We only need to look at the first operand of a DBG_VALUE, which eliminates the operand loop. Reviewers: aprantl, dblaikie, probinson Subscribers: MatzeB, qcolombet, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37929 llvm-svn: 313399
* Add AddresSpace to PseudoSourceValue.Jan Sjodin2017-09-141-1/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D35089 llvm-svn: 313297
* Re-land MachineInstr: Reason locally about some memory objects before going ↵Balaram Makam2017-08-301-17/+43
| | | | | | | | | | | | | | | | | | | | to AA. Summary: Reverts r311008 to reinstate r310825 with a fix. Refine alias checking for pseudo vs value to be conservative. This fixes the original failure in builtbot unittest SingleSource/UnitTests/2003-07-09-SignedArgs. Reviewers: hfinkel, nemanjai, efriedma Reviewed By: efriedma Subscribers: bjope, mcrosier, nhaehnle, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D36900 llvm-svn: 312126
* Revert "MachineInstr: Reason locally about some memory objects before going ↵Balaram Makam2017-08-161-42/+17
| | | | | | | | | | | | | to AA." r310825 caused the clang-ppc64le-linux-lnt bot to go red (http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/5712) because of a test-suite failure of SingleSource/UnitTests/2003-07-09-SignedArgs This reverts commit 0028f6a87224fb595a1c19c544cde9b003035996. llvm-svn: 311008
* MachineInstr: Reason locally about some memory objects before going to AA.Balaram Makam2017-08-141-17/+42
| | | | | | This addresses a FIXME in MachineInstr::mayAlias. llvm-svn: 310825
* [MachineOperand] Add ChangeToTargetIndex method. NFCMarcello Maggioni2017-08-041-0/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D36301 llvm-svn: 310083
* [SelectionDAG] Resolve PR33978.Simon Dardis2017-08-031-4/+2
| | | | | | | | | | | | | | | | | | | | | rL306209 taught SelectionDAG how to add the dereferenceable flag when expanding memcpy and memmove. The fix however contained a nit where the offset + size was constructed as an APInt of PointerSize rather than PointerSizeInBits. This lead to isDereferenceableAndAlignedPointer() get truncated values or values which would be sign extended within that function leading to incorrect results. Thanks to Alex Crichton for reporting the issue! This resolves PR33978. Reviewers: inouehrs Differential Revision: https://reviews.llvm.org/D36236 llvm-svn: 309930
* Remove the unused offset from DBG_VALUE (NFC)Adrian Prantl2017-07-281-12/+9
| | | | | | | Followup to r309426. rdar://problem/33580047 llvm-svn: 309450
* Add an ID field to StackObjectsMatt Arsenault2017-07-201-2/+3
| | | | | | | | | | | | | | | | | | | | | On AMDGPU SGPR spills are really spilled to another register. The spiller creates the spills to new frame index objects, which is used as a placeholder. This will eventually be replaced with a reference to a position in a VGPR to write to and the frame index deleted. It is most likely not a real stack location that can be shared with another stack object. This is a problem when StackSlotColoring decides it should combine a frame index used for a normal VGPR spill with a real stack location and a frame index used for an SGPR. Add an ID field so that StackSlotColoring has a way of knowing the different frame index types are incompatible. llvm-svn: 308673
* Replace -print-whole-regmask with a threshold.Matt Arsenault2017-07-201-5/+8
| | | | | | | | The previous flag/default of printing everything is not helpful when there are thousands of registers in the mask. llvm-svn: 308572
* [MIR] Add support for printing and parsing target MMO flagsGeoff Berry2017-07-131-0/+6
| | | | | | | | | | | | | | | | | Summary: Add target hooks for printing and parsing target MMO flags. Targets may override getSerializableMachineMemOperandTargetFlags() to return a mapping from string to flag value for target MMO values that should be serialized/parsed in MIR output. Add implementation of this hook for AArch64 SuppressPair MMO flag. Reviewers: bogner, hfinkel, qcolombet, MatzeB Subscribers: mcrosier, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D34962 llvm-svn: 307877
* Enhance synchscope representationKonstantin Zhuravlyov2017-07-111-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | OpenCL 2.0 introduces the notion of memory scopes in atomic operations to global and local memory. These scopes restrict how synchronization is achieved, which can result in improved performance. This change extends existing notion of synchronization scopes in LLVM to support arbitrary scopes expressed as target-specific strings, in addition to the already defined scopes (single thread, system). The LLVM IR and MIR syntax for expressing synchronization scopes has changed to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this replaces *singlethread* keyword), or a target-specific name. As before, if the scope is not specified, it defaults to CrossThread/System scope. Implementation details: - Mapping from synchronization scope name/string to synchronization scope id is stored in LLVM context; - CrossThread/System and SingleThread scopes are pre-defined to efficiently check for known scopes without comparing strings; - Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in the bitcode. Differential Revision: https://reviews.llvm.org/D21723 llvm-svn: 307722
* [GlobalIsel] allow x86_fp80 values to be dumped.Igor Breger2017-07-051-0/+8
| | | | | | | | | | | | | | | | Summary: Otherwise the fallback path fails with an assertion on x86_64 targets, when "x86_fp80" is encountered. Reviewers: t.p.northover, zvi, guyblank Reviewed By: zvi Subscribers: rovka, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D34975 llvm-svn: 307140
* Revert "r306529 - [X86] Correct dwarf unwind information in function epilogue"Daniel Jasper2017-06-291-34/+4
| | | | | | | | | | I am 99% sure that this breaks the PPC ASAN build bot: http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux/builds/3112/steps/64-bit%20check-asan/logs/stdio If it doesn't go back to green, we can recommit (and fix the original commit message at the same time :) ). llvm-svn: 306676
* [X86] Correct dwarf unwind information in function epiloguePetar Jovanovic2017-06-281-4/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CFI instructions that set appropriate cfa offset and cfa register are now inserted in emitEpilogue() in X86FrameLowering. Majority of the changes in this patch: 1. Ensure that CFI instructions do not affect code generation. 2. Enable maintaining correct information about cfa offset and cfa register in a function when basic blocks are reordered, merged, split, duplicated. These changes are target independent and described below. Changed CFI instructions so that they: 1. are duplicable 2. are not counted as instructions when tail duplicating or tail merging 3. can be compared as equal Add information to each MachineBasicBlock about cfa offset and cfa register that are valid at its entry and exit (incoming and outgoing CFI info). Add support for updating this information when basic blocks are merged, split, duplicated, created. Add a verification pass (CFIInfoVerifier) that checks that outgoing cfa offset and register of predecessor blocks match incoming values of their successors. Incoming and outgoing CFI information is used by a late pass (CFIInstrInserter) that corrects CFA calculation rule for a basic block if needed. That means that additional CFI instructions get inserted at basic block beginning to correct the rule for calculating CFA. Having CFI instructions in function epilogue can cause incorrect CFA calculation rule for some basic blocks. This can happen if, due to basic block reordering, or the existence of multiple epilogue blocks, some of the blocks have wrong cfa offset and register values set by the epilogue block above them. Patch by Violeta Vukobrat. Differential Revision: https://reviews.llvm.org/D18046 llvm-svn: 306529
* [SelectionDAG] set dereferenceable flag when expanding memcpy/memmoveHiroshi Inoue2017-06-241-0/+18
| | | | | | | | | | When SelectionDAG expands memcpy (or memmove) call into a sequence of load and store instructions, it disregards dereferenceable flag even the source pointer is known to be dereferenceable. This results in an assertion failure if SelectionDAG commonizes a load instruction generated for memcpy with another load instruction for the source pointer. This patch makes SelectionDAG to set the dereferenceable flag for the load instructions properly to avoid the assertion failure. Differential Revision: https://reviews.llvm.org/D34467 llvm-svn: 306209
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* [CodeGen] Fix some Clang-tidy modernize-use-using and Include What You Use ↵Eugene Zelenko2017-05-311-16/+38
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 304265
* MachineInstr: Do not skip dead def operands when printing.Matthias Braun2017-05-301-32/+0
| | | | | | | | This was introduced a long time ago in r86583 when regmask operands didn't exist. Nowadays the behavior hurts more than it helps. This removes it. llvm-svn: 304254
* Cleanup: Use DIExpression::prepend in buildDbgValueForSpill(). (NFC)Adrian Prantl2017-04-281-8/+3
| | | | llvm-svn: 301665
* [globalisel][tablegen] Revise API for ComplexPattern operands to improve ↵Daniel Sanders2017-04-221-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | flexibility. Summary: Some targets need to be able to do more complex rendering than just adding an operand or two to an instruction. For example, it may need to insert an instruction to extract a subreg first, or it may need to perform an operation on the operand. In SelectionDAG, targets would create SDNode's to achieve the desired effect during the complex pattern predicate. This worked because SelectionDAG had a form of garbage collection that would take care of SDNode's that were created but not used due to a later predicate rejecting a match. This doesn't translate well to GlobalISel and the churn was wasteful. The API changes in this patch enable GlobalISel to accomplish the same thing without the waste. The API is now: InstructionSelector::OptionalComplexRendererFn selectArithImmed(MachineOperand &Root) const; where Root is the root of the match. The return value can be omitted to indicate that the predicate failed to match, or a function with the signature ComplexRendererFn can be returned. For example: return OptionalComplexRendererFn( [=](MachineInstrBuilder &MIB) { MIB.addImm(Immed).addImm(ShVal); }); adds two immediate operands to the rendered instruction. Immed and ShVal are captured from the predicate function. As an added bonus, this also reduces the amount of information we need to provide to GIComplexOperandMatcher. Depends on D31418 Reviewers: aditya_nandakumar, t.p.northover, qcolombet, rovka, ab, javed.absar Reviewed By: ab Subscribers: dberris, kristof.beyls, igorb, llvm-commits Differential Revision: https://reviews.llvm.org/D31761 llvm-svn: 301079
* PR32382: Fix emitting complex DWARF expressions.Adrian Prantl2017-04-181-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DWARF specification knows 3 kinds of non-empty simple location descriptions: 1. Register location descriptions - describe a variable in a register - consist of only a DW_OP_reg 2. Memory location descriptions - describe the address of a variable 3. Implicit location descriptions - describe the value of a variable - end with DW_OP_stack_value & friends The existing DwarfExpression code is pretty much ignorant of these restrictions. This used to not matter because we only emitted very short expressions that we happened to get right by accident. This patch makes DwarfExpression aware of the rules defined by the DWARF standard and now chooses the right kind of location description for each expression being emitted. This would have been an NFC commit (for the existing testsuite) if not for the way that clang describes captured block variables. Based on how the previous code in LLVM emitted locations, DW_OP_deref operations that should have come at the end of the expression are put at its beginning. Fixing this means changing the semantics of DIExpression, so this patch bumps the version number of DIExpression and implements a bitcode upgrade. There are two major changes in this patch: I had to fix the semantics of dbg.declare for describing function arguments. After this patch a dbg.declare always takes the *address* of a variable as the first argument, even if the argument is not an alloca. When lowering a DBG_VALUE, the decision of whether to emit a register location description or a memory location description depends on the MachineLocation — register machine locations may get promoted to memory locations based on their DIExpression. (Future) optimization passes that want to salvage implicit debug location for variables may do so by appending a DW_OP_stack_value. For example: DBG_VALUE, [RBP-8] --> DW_OP_fbreg -8 DBG_VALUE, RAX --> DW_OP_reg0 +0 DBG_VALUE, RAX, DIExpression(DW_OP_deref) --> DW_OP_reg0 +0 All testcases that were modified were regenerated from clang. I also added source-based testcases for each of these to the debuginfo-tests repository over the last week to make sure that no synchronized bugs slip in. The debuginfo-tests compile from source and run the debugger. https://bugs.llvm.org/show_bug.cgi?id=32382 <rdar://problem/31205000> Differential Revision: https://reviews.llvm.org/D31439 llvm-svn: 300522
* GlobalISel: allow quad-precision values to be dumped.Tim Northover2017-03-201-0/+5
| | | | | | | Otherwise the fallback path fails with an assertion on AAPCS AArch64 targets, when "long double" is encountered. llvm-svn: 298273
* [globalisel][tblgen] Add support for ComplexPatternsDaniel Sanders2017-03-141-0/+8
| | | | | | | | | | | | | | | | | | | Summary: Adds a new kind of MachineOperand: MO_Placeholder. This operand must not appear in the MIR and only exists as a way of creating an 'uninitialized' operand until a matcher function overwrites it. Depends on D30046, D29712 Reviewers: t.p.northover, ab, rovka, aditya_nandakumar, javed.absar, qcolombet Reviewed By: qcolombet Subscribers: dberris, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D30089 llvm-svn: 297782
* Disable Callee Saved RegistersOren Ben Simhon2017-03-141-2/+15
| | | | | | | | | | | | | | Each Calling convention (CC) defines a static list of registers that should be preserved by a callee function. All other registers should be saved by the caller. Some CCs use additional condition: If the register is used for passing/returning arguments – the caller needs to save it - even if it is part of the Callee Saved Registers (CSR) list. The current LLVM implementation doesn’t support it. It will save a register if it is part of the static CSR list and will not care if the register is passed/returned by the callee. The solution is to dynamically allocate the CSR lists (Only for these CCs). The lists will be updated with actual registers that should be saved by the callee. Since we need the allocated lists to live as long as the function exists, the list should reside inside the Machine Register Info (MRI) which is a property of the Machine Function and managed by it (and has the same life span). The lists should be saved in the MRI and populated upon LowerCall and LowerFormalArguments. The patch will also assist to implement future no_caller_saved_regsiters attribute intended for interrupt handler CC. Differential Revision: https://reviews.llvm.org/D28566 llvm-svn: 297715
* Refactor alias check from MISched into common helper. NFC.Eli Friedman2017-03-091-0/+59
| | | | | | Differential Revision: https://reviews.llvm.org/D30598 llvm-svn: 297421
* [CodeGen] Print MI without a newline when skipping debugloc. NFC.Ahmed Bougacha2017-02-231-1/+3
| | | | | | | This matches the behavior for skip-operands. While there, document it. This is a follow-up to r296007. llvm-svn: 296011
* [CodeGen] Add a way to SkipDebugLoc in MachineInstr::print(). NFC.Ahmed Bougacha2017-02-231-4/+5
| | | | llvm-svn: 296007
* MachineInstr: Remove parameter from dump()Matthias Braun2017-01-291-2/+2
| | | | | | | | | | | | | The primary use of the dump() functions in LLVM is for use in a debugger. Unfortunately lldb does not seem to handle default arguments so using `p SomeMI.dump()` fails and you have to type the longer `p SomeMI.dump(nullptr)`. Remove the paramter to make the most common use easy. (You can always construct something like `p SomeMI.print(dbgs(),MyTII)` if you need more features). Differential Revision: https://reviews.llvm.org/D29241 llvm-svn: 293440
* Cleanup dump() functions.Matthias Braun2017-01-281-2/+2
| | | | | | | | | | | | | | | | | | We had various variants of defining dump() functions in LLVM. Normalize them (this should just consistently implement the things discussed in http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html For reference: - Public headers should just declare the dump() method but not use LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) - The definition of a dump method should look like this: #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) LLVM_DUMP_METHOD void MyClass::dump() { // print stuff to dbgs()... } #endif llvm-svn: 293359
* 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
OpenPOWER on IntegriCloud