summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/MIRParser/MIRParser.cpp
Commit message (Collapse)AuthorAgeFilesLines
* llc/MIR: Fix setFunctionAttributes for MIR functionsMatt Arsenault2020-01-061-17/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | A random set of attributes are implemented by llc/opt forcing the string attributes on the IR functions before processing anything. This would not happen for MIR functions, which have not yet been created at this point. Use a callback in the MIR parser, purely to avoid dealing with the ugliness that the command line flags are in a .inc file, and would require allowing access to these flags from multiple places (either from the MIR parser directly, or a new utility pass to implement these flags). It would probably be better to cleanup the flag handling into a separate library. This is in preparation for treating more command line flags with a corresponding function attribute in a more uniform way. The fast math flags in particular have a messy system where the command line flag sets the behavior from a function attribute if present, and otherwise the command line flag. This means if any other pass tries to inspect the function attributes directly, it will be inconsistent with the intended behavior. This is also inconsistent with the current behavior of -mcpu and -mattr, which overwrites any pre-existing function attributes. I would like to move this to consistenly have the command line flags not overwrite any pre-existing attributes, and to always ensure the command line flags are consistent with the function attributes.
* [Alignment][NFC] Remove unneeded llvm:: scoping on Align typesGuillaume Chatelet2019-09-271-1/+1
| | | | llvm-svn: 373081
* Add a missing space in a MIR parser error messageDavid Stenberg2019-09-201-1/+1
| | | | llvm-svn: 372398
* [Alignment] Use llvm::Align in MachineFunction and TargetLowering - fixes ↵Guillaume Chatelet2019-09-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | mir parsing Summary: This catches malformed mir files which specify alignment as log2 instead of pow2. See https://reviews.llvm.org/D65945 for reference, This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: MatzeB, qcolombet, dschuff, arsenm, sdardis, nemanjai, jvesely, nhaehnle, hiraditya, kbarton, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, Petar.Avramovic, asbirlea, s.egerton, pzheng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67433 llvm-svn: 371608
* [LLVM][Alignment] Make functions using log of alignment explicitGuillaume Chatelet2019-09-051-1/+1
| | | | | | | | | | | | | | | | | | | | | Summary: This patch renames functions that takes or returns alignment as log2, this patch will help with the transition to llvm::Align. The renaming makes it explicit that we deal with log(alignment) instead of a power of two alignment. A few renames uncovered dubious assignments: - `MirParser`/`MirPrinter` was expecting powers of two but `MachineFunction` and `MachineBasicBlock` were using deal with log2(align). This patch fixes it and updates the documentation. - `MachineBlockPlacement` exposes two flags (`align-all-blocks` and `align-all-nofallthru-blocks`) supposedly interpreted as power of two alignments, internally these values are interpreted as log2(align). This patch updates the documentation, - `MachineFunctionexposes` exposes `align-all-functions` also interpreted as power of two alignment, internally this value is interpreted as log2(align). This patch updates the documentation, Reviewers: lattner, thegameg, courbet Subscribers: dschuff, arsenm, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, javed.absar, hiraditya, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, Jim, s.egerton, llvm-commits, courbet Tags: #llvm Differential Revision: https://reviews.llvm.org/D65945 llvm-svn: 371045
* [DebugInfo] Allow bundled calls in the MIR's call site infoDavid Stenberg2019-08-191-2/+2
| | | | | | | | | | | | | | | | | | Summary: Extend the MIR parser and writer so that the call site information can refer to calls that are bundled. Reviewers: aprantl, asowda, NikolaPrica, djtodoro, ivanbaev, vsk Reviewed By: aprantl Subscribers: arsenm, hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D66145 llvm-svn: 369256
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-151-4/+4
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* Finish moving TargetRegisterInfo::isVirtualRegister() and friends to ↵Daniel Sanders2019-08-011-1/+1
| | | | | | llvm::Register as started by r367614. NFC llvm-svn: 367633
* [MachineFunction] Base support for call site info trackingDjordje Todorovic2019-06-271-0/+47
| | | | | | | | | | | | | | Add an attribute into the MachineFunction that tracks call site info. ([8/13] Introduce the debug entry values.) Co-authored-by: Ananth Sowda <asowda@cisco.com> Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com> Co-authored-by: Ivan Baev <ibaev@cisco.com> Differential Revision: https://reviews.llvm.org/D61061 llvm-svn: 364506
* Describe stack-id as an enumSander de Smalen2019-06-171-0/+9
| | | | | | | | | | | | | | | | | This patch changes MIR stack-id from an integer to an enum, and adds printing/parsing support for this in MIR files. The default stack-id '0' is now renamed to 'default'. This should make MIR tests that have stack objects with different stack-ids more descriptive. It also clarifies code operating on StackID. Reviewers: arsenm, thegameg, qcolombet Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D60137 llvm-svn: 363533
* Enforce StackID definition in PEISander de Smalen2019-04-021-3/+3
| | | | | | | | | | | | | | | There are various places in LLVM where the definition of StackID is not properly honoured, for example in PEI where objects with a StackID > 0 are allocated on the default stack (StackID0). This patch enforces that PEI only considers allocating objects to StackID 0. Reviewers: arsenm, thegameg, MatzeB Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D60062 llvm-svn: 357460
* MIR: Freeze reserved regs after parsing everythingMatt Arsenault2019-03-271-3/+8
| | | | | | | | | | | | The AMDGPU implementation of getReservedRegs depends on MachineFunctionInfo fields that are parsed from the YAML section. This was reserving the wrong register since it was setting the reserved regs before parsing the correct one. Some tests were relying on the default reserved set for the assumed default calling convention. llvm-svn: 357083
* MIR: Allow targets to serialize MachineFunctionInfoMatt Arsenault2019-03-141-1/+20
| | | | | | | | | | | | | | | | | | This has been a very painful missing feature that has made producing reduced testcases difficult. In particular the various registers determined for stack access during function lowering were necessary to avoid undefined register errors in a large percentage of cases. Implement a subset of the important fields that need to be preserved for AMDGPU. Most of the changes are to support targets parsing register fields and properly reporting errors. The biggest sort-of bug remaining is for fields that can be initialized from the IR section will be overwritten by a default initialized machineFunctionInfo section. Another remaining bug is the machineFunctionInfo section is still printed even if empty. llvm-svn: 356215
* MIR: Stop reinitializing target information for every useMatt Arsenault2019-03-121-66/+12
| | | | | | | | | | | | | | | Every time a physical register reference was parsed, this would initialize a string map for every register in in target, and discard it for the next. The same applies for the other fields initialized from target information. Follow along with how the function state is tracked, and add a new tracking class for target information. The string->register class/register bank for some reason were kept separately, so track them in the same place. llvm-svn: 355970
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-011-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc doesn't choke on it, hopefully. Original Message: The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352827
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-311-3/+2
| | | | | | | | | This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791). Seems to run into compilation failures with GCC (but not clang, where I tested it). Reverting while I investigate. llvm-svn: 352800
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-01-311-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352791
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [MIR] Add hasWinCFI fieldSanjin Sijaric2018-10-241-0/+1
| | | | | | | | | Adding hasWinCFI field so that I can add MIR test cases to https://reviews.llvm.org/D50166. Differential Revision: https://reviews.llvm.org/D51201 llvm-svn: 345196
* [codeview] Emit S_FRAMEPROC and use S_DEFRANGE_FRAMEPOINTER_RELReid Kleckner2018-10-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this change, LLVM would always describe locals on the stack as being relative to some specific register, RSP, ESP, EBP, ESI, etc. Variables in stack memory are pretty common, so there is a special S_DEFRANGE_FRAMEPOINTER_REL symbol for them. This change uses it to reduce the size of our debug info. On top of the size savings, there are cases on 32-bit x86 where local variables are addressed from ESP, but ESP changes across the function. Unlike in DWARF, there is no FPO data to describe the stack adjustments made to push arguments onto the stack and pop them off after the call, which makes it hard for the debugger to find the local variables in frames further up the stack. To handle this, CodeView has a special VFRAME register, which corresponds to the $T0 variable set by our FPO data in 32-bit. Offsets to local variables are instead relative to this value. This is part of PR38857. Reviewers: hans, zturner, javed.absar Subscribers: aprantl, hiraditya, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D52217 llvm-svn: 343543
* [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-301-3/+13
| | | | llvm-svn: 328887
* [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
* 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
* 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
* MachineFunction: Return reference from getFunction(); NFCMatthias Braun2017-12-151-2/+2
| | | | | | The Function can never be nullptr so we can return a reference. llvm-svn: 320884
* 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
* 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
* [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
* llc: Add ability to parse mir from stdinMatthias Braun2017-06-061-1/+1
| | | | | | | | - Add -x <language> option to switch between IR and MIR inputs. - Change MIR parser to read from stdin when filename is '-'. - Add a simple mir roundtrip test. llvm-svn: 304825
* CodeGen: Refactor MIR parsingMatthias Braun2017-06-061-57/+79
| | | | | | | | | | | | When parsing .mir files immediately construct the MachineFunctions and put them into MachineModuleInfo. This allows us to get rid of the delayed construction (and delayed error reporting) through the MachineFunctionInitialzier interface. Differential Revision: https://reviews.llvm.org/D33809 llvm-svn: 304758
* MIR: remove explicit "noVRegs" property.Tim Northover2017-05-301-2/+0
| | | | | | | We can infer this from the incoming MIR, so there's no reason to represent it with a special flag. llvm-svn: 304246
* MachineFrameInfo: Track whether MaxCallFrameSize is computed yet; NFCMatthias Braun2017-05-011-1/+2
| | | | | | | | | | This tracks whether MaxCallFrameSize is computed yet. Ideally we would assert and fail when the value is queried before it is computed, however this fails various targets that need to be fixed first. Differential Revision: https://reviews.llvm.org/D32570 llvm-svn: 301851
* MIR: Allow parsing of empty machine functionsJustin Bogner2017-04-111-3/+0
| | | | | | | | | | | | If you run llc -stop-after=codegenprepare and feed the resulting MIR to llc -start-after=codegenprepare, you'll have an empty machine function since we haven't run any isel yet. Of course, this only works if the MIRParser believes you that this is okay. This is essentially a revert of r241862 with a fix for the problem it was papering over. llvm-svn: 299975
* [MIR] Support Customed Register Mask and CSRsOren Ben Simhon2017-03-191-18/+18
| | | | | | | | | | | | | The MIR printer dumps a string that describe the register mask of a function. A static predefined list of register masks matches a static list of strings. However when the register mask is not from the static predefined list, there is no descriptor string and the printer fails. This patch adds support to custom register mask printing and dumping. Also the list of callee saved registers (describing the registers that must be preserved for the caller) might be dynamic. As such this data needs to be dumped and parsed back to the Machine Register Info. Differential Revision: https://reviews.llvm.org/D30971 llvm-svn: 298207
* ARM: avoid clobbering register in v6 jump-table expansion.Tim Northover2017-03-151-0/+2
| | | | | | | | | | | If we got unlucky with register allocation and actual constpool placement, we could end up producing a tTBB_JT with an index that's already been clobbered. Technically, we might be able to fix this situation up with a MOV, but I think the constant islands pass is complex enough without having to deal with more weird edge-cases. llvm-svn: 297871
* MIRParser: Allow regclass specification on operandMatthias Braun2017-01-181-5/+6
| | | | | | | | | | | You can now define the register class of a virtual register on the operand itself avoiding the need to use a "registers:" block. Example: "%0:gr64 = COPY %rax" Differential Revision: https://reviews.llvm.org/D22398 llvm-svn: 292321
* Move VariableDbgInfo from MachineModuleInfo to MachineFunctionMatthias Braun2016-11-301-1/+1
| | | | | | | | | | | VariableDbgInfo is per function data, so it makes sense to have it with the function instead of the module. This is a necessary step to have machine module passes work properly. Differential Revision: https://reviews.llvm.org/D27186 llvm-svn: 288292
* MIRParser: Add support for parsing vreg reg alloc hintsTom Stellard2016-11-151-2/+3
| | | | | | | | | | Reviewers: qcolombet, MatzeB Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D26573 llvm-svn: 286911
* MIRParser: Rewrite register info initialization; mostly NFCMatthias Braun2016-10-111-43/+74
| | | | | | | | | | | | | | | | | | | | | | This changes MachineRegisterInfo to be initializes after parsing all instructions. This is in preparation for upcoming commits that allow the register class specification on the operand or deduce them from the MCInstrDesc. This commit removes the unused feature of having nonsequential register numbers. This was confusing anyway as the vreg numbers would be different after parsing when you had "holes" in your numbering. This patch also introduces the concept of an incomplete virtual register. An incomplete virtual register may be used during .mir parsing to construct MachineOperands without knowing the exact register class (or register bank) yet. NFC except for some error messages. Differential Revision: https://reviews.llvm.org/D22397 llvm-svn: 283848
* Don't create a SymbolTable in Function when the LLVMContext discards value ↵Mehdi Amini2016-09-171-1/+1
| | | | | | | | | | | | | | names (NFC) The ValueSymbolTable is used to detect name conflict and rename instructions automatically. This is not needed when the value names are automatically discarded by the LLVMContext. No functional change intended, just saving a little bit of memory. This is a recommit of r281806 after fixing the accessor to return a pointer instead of a reference and updating all the call-sites. llvm-svn: 281813
* [MIR Parser] Fix Build!Mehdi Amini2016-09-171-1/+1
| | | | | | Last-second refactoring before push was bad idea... llvm-svn: 281812
* MIR Parser: issue an error when the Context discard value names.Mehdi Amini2016-09-171-0/+8
| | | | | | This is in line with the LLParser behavior llvm-svn: 281811
* GlobalISel: disambiguate types when printing MIRTim Northover2016-09-121-2/+2
| | | | | | | | | | | | | | | | | Some generic instructions have multiple types. While in theory these always be discovered by inspecting the single definition of each generic vreg, in practice those definitions won't always be local and traipsing through a big function to find them will not be fun. So this changes MIRPrinter to print out the type of uses as well as defs, if they're known to be different or not known to be the same. On the parsing side, we're a little more flexible: provided each register is given a type in at least one place it's mentioned (and all types are consistent) we accept the MIR. This doesn't introduce ambiguity but makes writing tests manually a bit less painful. llvm-svn: 281204
* GlobalISel: move type information to MachineRegisterInfo.Tim Northover2016-09-091-2/+2
| | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud