summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/MIRParser
Commit message (Collapse)AuthorAgeFilesLines
...
* Reapply changes reverted by r343235Luke Cheeseman2018-09-283-0/+6
| | | | | | | | - Add fix so that all code paths that create DWARFContext with an ObjectFile initialise the target architecture in the context - Add an assert that the Arch is known in the Dwarf CallFrameString method llvm-svn: 343317
* Revert r343192 as an ubsan build is currently failingLuke Cheeseman2018-09-273-6/+0
| | | | llvm-svn: 343235
* Reapply changes reverted in r343114, lldb patch to follow shortlyLuke Cheeseman2018-09-273-0/+6
| | | | llvm-svn: 343192
* Revert r343112 as CallFrameString API change has broken lldb buildsLuke Cheeseman2018-09-263-6/+0
| | | | llvm-svn: 343114
* [AArch64] - Return address signing dwarf supportLuke Cheeseman2018-09-263-0/+6
| | | | | | - Reapply r343089 with a fix for DebugInfo/Sparc/gnu-window-save.ll llvm-svn: 343112
* Revert r343089 "[AArch64] - Return address signing dwarf support"Hans Wennborg2018-09-263-6/+0
| | | | | | | | | | | | | | | | | | | This caused the DebugInfo/Sparc/gnu-window-save.ll test to fail. > Functions that have signed return addresses need additional dwarf support: > - After signing the LR, and before authenticating it, the LR register is in a > state the is unusable by a debugger or unwinder > - To account for this a new directive, .cfi_negate_ra_state, is added > - This directive says the signed state of the LR register has now changed, > i.e. unsigned -> signed or signed -> unsigned > - This directive has the same CFA code as the SPARC directive GNU_window_save > (0x2d), adding a macro to account for multiply defined codes > - This patch matches the gcc implementation of this support: > https://patchwork.ozlabs.org/patch/800271/ > > Differential Revision: https://reviews.llvm.org/D50136 llvm-svn: 343103
* [AArch64] - Return address signing dwarf supportLuke Cheeseman2018-09-263-0/+6
| | | | | | | | | | | | | | | | | Functions that have signed return addresses need additional dwarf support: - After signing the LR, and before authenticating it, the LR register is in a state the is unusable by a debugger or unwinder - To account for this a new directive, .cfi_negate_ra_state, is added - This directive says the signed state of the LR register has now changed, i.e. unsigned -> signed or signed -> unsigned - This directive has the same CFA code as the SPARC directive GNU_window_save (0x2d), adding a macro to account for multiply defined codes - This patch matches the gcc implementation of this support: https://patchwork.ozlabs.org/patch/800271/ Differential Revision: https://reviews.llvm.org/D50136 llvm-svn: 343089
* add IR flags to MIMichael Berg2018-09-113-1/+16
| | | | | | | | | | | | | | Summary: Initial support for nsw, nuw and exact flags in MI Reviewers: spatel, hfinkel, wristow Reviewed By: spatel Subscribers: nlopes Differential Revision: https://reviews.llvm.org/D51738 llvm-svn: 341996
* Consistently use MemoryLocation::UnknownSize to indicate unknown access sizeKrzysztof Parzyszek2018-08-203-6/+15
| | | | | | | | | | | | 1. Change the software pipeliner to use unknown size instead of dropping memory operands. It used to do it before, but MachineInstr::mayAlias did not handle it correctly. 2. Recognize UnknownSize in MachineInstr::mayAlias. 3. Print and parse UnknownSize in MIR. Differential Revision: https://reviews.llvm.org/D50339 llvm-svn: 340208
* [x86/MIR] Implement support for pre- and post-instruction symbols, asChandler Carruth2018-08-163-4/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | well as MIR parsing support for `MCSymbol` `MachineOperand`s. The only real way to test pre- and post-instruction symbol support is to use them in operands, so I ended up implementing that within the patch as well. I can split out the operand support if folks really want but it doesn't really seem worth it. The functional implementation of pre- and post-instruction symbols is now *completely trivial*. Two tiny bits of code in the (misnamed) AsmPrinter. It should be completely target independent as well. We emit these exactly the same way as we emit basic block labels. Most of the code here is to give full dumping, MIR printing, and MIR parsing support so that we can write useful tests. The MIR parsing of MC symbol operands still isn't 100%, as it forces the symbols to be non-temporary and non-local symbols with names. However, those names often can encode most (if not all) of the special semantics desired, and unnamed symbols seem especially annoying to serialize and de-serialize. While this isn't perfect or full support, it seems plenty to write tests that exercise usage of these kinds of operands. The MIR support for pre-and post-instruction symbols was quite straightforward. I chose to print them out in an as-if-operand syntax similar to debug locations as this seemed the cleanest way and let me use nice introducer tokens rather than inventing more magic punctuation like we use for memoperands. However, supporting MIR-based parsing of these symbols caused me to change the design of the symbol support to allow setting arbitrary symbols. Without this, I don't see any reasonable way to test things with MIR. Differential Revision: https://reviews.llvm.org/D50833 llvm-svn: 339962
* [MI] Change the array of `MachineMemOperand` pointers to beChandler Carruth2018-08-161-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a generically extensible collection of extra info attached to a `MachineInstr`. The primary change here is cleaning up the APIs used for setting and manipulating the `MachineMemOperand` pointer arrays so chat we can change how they are allocated. Then we introduce an extra info object that using the trailing object pattern to attach some number of MMOs but also other extra info. The design of this is specifically so that this extra info has a fixed necessary cost (the header tracking what extra info is included) and everything else can be tail allocated. This pattern works especially well with a `BumpPtrAllocator` which we use here. I've also added the basic scaffolding for putting interesting pointers into this, namely pre- and post-instruction symbols. These aren't used anywhere yet, they're just there to ensure I've actually gotten the data structure types correct. I'll flesh out support for these in a subsequent patch (MIR dumping, parsing, the works). Finally, I've included an optimization where we store any single pointer inline in the `MachineInstr` to avoid the allocation overhead. This is expected to be the overwhelmingly most common case and so should avoid any memory usage growth due to slightly less clever / dense allocation when dealing with >1 MMO. This did require several ergonomic improvements to the `PointerSumType` to reasonably support the various usage models. This also has a side effect of freeing up 8 bits within the `MachineInstr` which could be repurposed for something else. The suggested direction here came largely from Hal Finkel. I hope it was worth it. ;] It does hopefully clear a path for subsequent extensions w/o nearly as much leg work. Lots of thanks to Reid and Justin for careful reviews and ideas about how to do all of this. Differential Revision: https://reviews.llvm.org/D50701 llvm-svn: 339940
* CodeGen: Cleanup regmask construction; NFCMatthias Braun2018-07-261-6/+2
| | | | | | | | | - Avoid duplication of regmask size calculation. - Simplify allocateRegisterMask() call. - Rename allocateRegisterMask() to allocateRegMask() to be consistent with naming in MachineOperand. llvm-svn: 337986
* [CodeGen] Fix inconsistent declaration parameter nameFangrui Song2018-07-162-3/+3
| | | | llvm-svn: 337200
* [MIRParser] Update a diagnostic message to use the correct register sigil. NFCMatt Davis2018-06-191-1/+1
| | | | | | | | | | | | | | | | | | Summary: Patch r323922 changed the sigil for physical registers to '$', instead of '%'. An error message was missed during this change, and reports the wrong sigil. This patch corrects that diagnostic and the tests that check that error string. Reviewers: zer0, bjope Reviewed By: bjope Subscribers: bjope, thegameg, plotfi, llvm-commits Differential Revision: https://reviews.llvm.org/D48086 llvm-svn: 335066
* [MIRParser] Add parser support for 'true' and 'false' i1s.Amara Emerson2018-06-051-2/+5
| | | | | | | | | We already output true and false in the printer, but the parser isn't able to read it. Differential Revision: https://reviews.llvm.org/D47424 llvm-svn: 333970
* [MIRParser][GlobalISel] Parsing vector pointer types (<M x pA>)Roman Tereshin2018-05-081-13/+20
| | | | | | | | | | | | | | MIParser wasn't able to parse LLTs like `<4 x p0>`, fixing that. Reviewers: qcolombet t.p.northover aditya_nandakumar Reviewed By: qcolombet Subscribers: rovka, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D46490 llvm-svn: 331712
* [MIRPraser] Improve error checking for typed immediate operandsHeejin Ahn2018-05-051-6/+13
| | | | | | | | | | | | | | Summary: This improves error checks for typed immediate operands introduced in D45948 (rL331586), and removes a code block copied by mistake. Reviewers: rtereshin Subscribers: dschuff, sbc100, jgravelle-google, llvm-commits Differential Revision: https://reviews.llvm.org/D46491 llvm-svn: 331600
* [MIRParser] Allow register class names in the form of integer/scalarHeejin Ahn2018-05-053-29/+18
| | | | | | | | | | | | | | | | Summary: The current code cannot handle register class names like 'i32', which is a valid register class name in WebAssembly. This patch removes special handling for integer/scalar/pointer type parsing and treats them as normal identifiers. Reviewers: thegameg Subscribers: jfb, dschuff, sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D45948 llvm-svn: 331586
* MachineInst support mapping SDNode fast math flags for support in Back End ↵Michael Berg2018-05-033-6/+43
| | | | | | | | | | | | | | | | | | code generation Summary: Machine Instruction flags for fast math support and MIR print support Reviewers: spatel, arsenm Reviewed By: arsenm Subscribers: wdng Differential Revision: https://reviews.llvm.org/D45781 llvm-svn: 331417
* [MIR] Add support for debug metadata for fixed stack objectsFrancis Visoiu Mistrih2018-04-251-4/+7
| | | | | | | | | | | | | | | Debug var, expr and loc were only supported for non-fixed stack objects. This patch adds the following fields to the "fixedStack:" entries, and renames the ones from "stack:" to: * debug-info-variable * debug-info-expression * debug-info-location Differential Revision: https://reviews.llvm.org/D46032 llvm-svn: 330859
* [MIR] Add support for MachineFrameInfo::LocalFrameSizeFrancis Visoiu Mistrih2018-04-061-0/+1
| | | | | | | | | | MFI.LocalFrameSize was not serialized. It is usually set from LocalStackSlotAllocation, so if that pass doesn't run it is impossible do deduce it from the stack objects. Until now, this information was lost. llvm-svn: 329382
* [MIR] Adding support for Named Virtual Registers in MIR.Puyan Lotfi2018-03-305-5/+56
| | | | llvm-svn: 328887
* [MIR] Allow frame-setup and frame-destroy on the same instructionFrancis Visoiu Mistrih2018-03-131-5/+7
| | | | | | | | | | | | | | | Nothing prevents us from having both frame-setup and frame-destroy on the same instruction. When merging: * frame-setup OPCODE1 * frame-destroy OPCODE2 into * frame-setup frame-destroy OPCODE3 we want to be able to print and parse both flags. llvm-svn: 327442
* [GlobalISel] Print/Parse FailedISel MachineFunction propertyRoman Tereshin2018-02-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | FailedISel MachineFunction property is part of the CodeGen pipeline state as much as every other property, notably, Legalized, RegBankSelected, and Selected. Let's make that part of the state also serializable / de-serializable, so if GlobalISel aborts on some of the functions of a large module, but not the others, it could be easily seen and the state of the pipeline could be maintained through llc's invocations with -stop-after / -start-after. To make MIR printable and generally to not to break it too much too soon, this patch also defers cleaning up the vreg -> LLT map until ResetMachineFunctionPass. To make MIR with FailedISel: true also machine verifiable, machine verifier is changed so it treats a MIR-module as non-regbankselected and non-selected if there is FailedISel property set. Reviewers: qcolombet, ab Reviewed By: dsanders Subscribers: javed.absar, rovka, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D42877 llvm-svn: 326343
* Followup on Proposal to move MIR physical register namespace to '$' sigil.Puyan Lotfi2018-01-311-7/+16
| | | | | | | | | | | | Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
* LLParser: add an argument for overriding data layout and do not check alloca ↵Yaxun Liu2018-01-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | addr space Sometimes users do not specify data layout in LLVM assembly and let llc set the data layout by target triple after loading the LLVM assembly. Currently the parser checks alloca address space no matter whether the LLVM assembly contains data layout definition, which causes false alarm since the default data layout does not contain the correct alloca address space. The parser also calls verifier to check debug info and updating invalid debug info. Currently there is no way to let the verifier to check debug info only. If the verifier finds non-debug-info issues the parser will fail. For llc, the fix is to remove the check of alloca addr space in the parser and disable updating debug info, and defer the updating of debug info and verification to be after setting data layout of the IR by target. For other llvm tools, since they do not override data layout by target but instead can override data layout by a command line option, an argument for overriding data layout is added to the parser. In cases where data layout overriding is necessary for the parser, the data layout can be provided by command line. Differential Revision: https://reviews.llvm.org/D41832 llvm-svn: 323826
* [MIR] Add support for addrspace in MIRFrancis Visoiu Mistrih2018-01-263-0/+18
| | | | | | | | | | Add support for printing / parsing the addrspace of a MachineMemOperand. Fixes PR35970. Differential Revision: https://reviews.llvm.org/D42502 llvm-svn: 323521
* AArch64: Fix emergency spillslot being out of reach for large callframesMatthias Braun2018-01-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Re-commit of r322200: The testcase shouldn't hit machineverifiers anymore with r322917 in place. Large callframes (calls with several hundreds or thousands or parameters) could lead to situations in which the emergency spillslot is out of range to be addressed relative to the stack pointer. This commit forces the use of a frame pointer in the presence of large callframes. This commit does several things: - Compute max callframe size at the end of instruction selection. - Add mirFileLoaded target callback. Use it to compute the max callframe size after loading a .mir file when the size wasn't specified in the file. - Let TargetFrameLowering::hasFP() return true if there exists a callframe > 255 bytes. - Always place the emergency spillslot close to FP if we have a frame pointer. - Note that `useFPForScavengingIndex()` would previously return false when a base pointer was available leading to the emergency spillslot getting allocated late (that's the whole effect of this callback). Which made no sense to me so I took this case out: Even though the emergency spillslot is technically not referenced by FP in this case we still want it allocated early. Differential Revision: https://reviews.llvm.org/D40876 llvm-svn: 322919
* Revert "AArch64: Fix emergency spillslot being out of reach for large ↵Matthias Braun2018-01-101-2/+0
| | | | | | | | | | | | callframes" Revert for now as the testcase is hitting a pre-existing verifier error that manifest as a failure when expensive checks are enabled (or -verify-machineinstrs) is used. This reverts commit r322200. llvm-svn: 322231
* AArch64: Fix emergency spillslot being out of reach for large callframesMatthias Braun2018-01-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Large callframes (calls with several hundreds or thousands or parameters) could lead to situations in which the emergency spillslot is out of range to be addressed relative to the stack pointer. This commit forces the use of a frame pointer in the presence of large callframes. This commit does several things: - Compute max callframe size at the end of instruction selection. - Add mirFileLoaded target callback. Use it to compute the max callframe size after loading a .mir file when the size wasn't specified in the file. - Let TargetFrameLowering::hasFP() return true if there exists a callframe > 255 bytes. - Always place the emergency spillslot close to FP if we have a frame pointer. - Note that `useFPForScavengingIndex()` would previously return false when a base pointer was available leading to the emergency spillslot getting allocated late (that's the whole effect of this callback). Which made no sense to me so I took this case out: Even though the emergency spillslot is technically not referenced by FP in this case we still want it allocated early. Differential Revision: https://reviews.llvm.org/D40876 llvm-svn: 322200
* [MIR] Repurposing '$' sigil used by external symbols. Replacing with '&'.Puyan Lotfi2018-01-101-1/+1
| | | | | | | | | | Planning to add support for named vregs. This puts is in a conundrum since physregs are named as well. To rectify this we need to use a sigil other than '%' for physregs in MIR. We've settled on using '$' for physregs but first we must repurpose it from external symbols using it, which is what this commit is all about. We think '&' will have familiar semantics for C/C++ users. llvm-svn: 322146
* [MIR] Add support for the frame-destroy MachineInstr flagFrancis Visoiu Mistrih2018-01-093-0/+5
| | | | | | | | | We are printing / parsing the `frame-setup` MachineInstr flag but not the `frame-destroy` one. Differential Revision: https://reviews.llvm.org/D41509 llvm-svn: 322071
* MachineFunction: Return reference from getFunction(); NFCMatthias Braun2017-12-152-13/+13
| | | | | | The Function can never be nullptr so we can return a reference. llvm-svn: 320884
* [MIR] Add support for missing CFI directivesFrancis Visoiu Mistrih2017-12-153-0/+83
| | | | | | | | | | | | | | | | | | | The following CFI directives are suported by MC but not by MIR: * .cfi_rel_offset * .cfi_adjust_cfa_offset * .cfi_escape * .cfi_remember_state * .cfi_restore_state * .cfi_undefined * .cfi_register * .cfi_window_save Add support for printing, parsing and update tests. Differential Revision: https://reviews.llvm.org/D41230 llvm-svn: 320819
* Remove redundant includes from lib/CodeGen.Michael Zolotukhin2017-12-131-1/+0
| | | | llvm-svn: 320619
* [MachineOperand][MIR] Add isRenamable to MachineOperand.Geoff Berry2017-12-123-2/+10
| | | | | | | | | | | | | | | | | | Summary: Add isRenamable() predicate to MachineOperand. This predicate can be used by machine passes after register allocation to determine whether it is safe to rename a given register operand. Register operands that aren't marked as renamable may be required to be assigned their current register to satisfy constraints that are not captured by the machine IR (e.g. ABI or ISA constraints). Reviewers: qcolombet, MatzeB, hfinkel Subscribers: nemanjai, mcrosier, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D39400 llvm-svn: 320503
* [CodeGen] Unify MBB reference format in both MIR and debug outputFrancis Visoiu Mistrih2017-12-042-0/+5
| | | | | | | | | | | | | | | | As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
* [mir] Print/Parse both MOLoad and MOStore when they occur together.Daniel Sanders2017-11-281-1/+11
| | | | | | | | | | | | | | | | | | Summary: They're not always mutually exclusive. read-modify-write atomics are both at the same time. One example of this is the SWP instructions on AArch64. Another example is GlobalISel's G_ATOMICRMW_* generic instructions which will be added in a later patch. Reviewers: arphaman, aemerson Reviewed By: aemerson Subscribers: aemerson, javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D40157 llvm-svn: 319202
* MIRParser: Avoid reading uninitialized memory on generic vregsJustin Bogner2017-11-171-0/+1
| | | | | | | | | | | | | | If a vreg's bank is specified in the registers block and one of its defs or uses also specifies the bank, we end up checking that the RegBank is equal to diagnose conflicting banks. The problem comes up for generic vregs, where we weren't fully initializing the VRegInfo when parsing the registers block, so we'd end up comparing a null pointer to uninitialized memory. This fixes a non-deterministic failure when round tripping through MIR with generic vregs. llvm-svn: 318543
* 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
* Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layeringDavid Blaikie2017-11-081-3/+3
| | | | | | | | 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
* [AsmPrinterDwarf] Add support for .cfi_restore directiveFrancis Visoiu Mistrih2017-11-023-0/+9
| | | | | | | | | | | | | | As of today we only use .cfi_offset to specify the offset of a CSR, but we never use .cfi_restore when the CSR is restored. If we want to perform a more advanced type of shrink-wrapping, we need to use .cfi_restore in order to switch the CFI state between blocks. This patch only aims at adding support for the directive. Differential Revision: https://reviews.llvm.org/D36114 llvm-svn: 317199
* Add DK_Remark to SMDiagnosticAdam Nemet2017-10-121-0/+3
| | | | | | | | | | | Swift uses SMDiagnostic for diagnostic messages. For https://github.com/apple/swift/pull/12294, we need remark support. I picked the color that clang uses to display them. Differential Revision: https://reviews.llvm.org/D38865 llvm-svn: 315642
* MIR: Serialize CaleeSavedInfo Restored flagMatthias Braun2017-09-281-5/+7
| | | | llvm-svn: 314449
* [CodeGen] Fix some Clang-tidy modernize-use-default-member-init and Include ↵Eugene Zelenko2017-09-272-11/+17
| | | | | | What You Use warnings; other minor fixes (NFC). llvm-svn: 314363
* [MIParser] Ensure getHexUint doesn't produce APInts with a bitwidth of 0Jessica Paquette2017-09-011-2/+5
| | | | | | | | | | | | | | | | | | | | | If getHexUint reads in a hex 0, it will create an APInt with a value of 0. The number of active bits on this APInt is used to calculate the bitwidth of Result. The number of active bits is defined as an APInt's bitwidth - its number of leading 0s. Since this APInt is 0, its bitwidth and number of leading 0s are equal. Thus, Result is constructed with a bitwidth of 0, triggering an APInt assert. This commit fixes that by checking if the APInt is equal to 0, and setting the bitwidth to 32 if it is. Otherwise, it sets the bitwidth using getActiveBits. This caused issues when compiling MIR files with successor probabilities. In the case that a successor is tagged with a probability of 0, this assert would fire on debug builds. https://reviews.llvm.org/D37401 llvm-svn: 312387
* Attempt to fix the BUILD_SHARED_LIBS build after the DIExpression changeReid Kleckner2017-08-231-1/+1
| | | | llvm-svn: 311595
* Parse and print DIExpressions inline to ease IR and MIR testingReid Kleckner2017-08-233-5/+61
| | | | | | | | | | | | | | | | | | | Summary: Most DIExpressions are empty or very simple. When they are complex, they tend to be unique, so checking them inline is reasonable. This also avoids the need for CodeGen passes to append to the llvm.dbg.mir named md node. See also PR22780, for making DIExpression not be an MDNode. Reviewers: aprantl, dexonsmith, dblaikie Subscribers: qcolombet, javed.absar, eraman, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D37075 llvm-svn: 311594
* [MIR] Print target-specific constant poolsDiana Picus2017-08-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | This should enable us to test the generation of target-specific constant pools, e.g. for ARM: constants: - id: 0 value: 'g(GOT_PREL)-(LPC0+8-.)' alignment: 4 isTargetSpecific: true I intend to use this to test PIC support in GlobalISel for ARM. This is difficult to test outside of that context, since the existing MIR tests usually rely on parser support as well, and that seems a bit trickier to add. We could try to add a unit test, but the setup for that seems rather convoluted and overkill. We do test however that the parser reports a nice error when encountering a target-specific constant pool. Differential Revision: https://reviews.llvm.org/D36092 llvm-svn: 309806
* Add an ID field to StackObjectsMatt Arsenault2017-07-201-0/+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
OpenPOWER on IntegriCloud