summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/GlobalISel/MachineIRBuilder.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [GlobalISel] Include missing change from r356396Amara Emerson2019-03-181-4/+2
| | | | | | Forgot to add a change to relax some asserts in r356396. llvm-svn: 356411
* Revert r356304: remove subreg parameter from MachineIRBuilder::buildCopy()Amara Emerson2019-03-181-5/+5
| | | | | | | | | | | | | After review comments, it was preferred to not teach MachineIRBuilder about non-generic instructions beyond using buildInstr(). For AArch64 I've changed the buildCopy() calls to buildInstr() + a separate addReg() call. This also relaxes the MachineIRBuilder's COPY checking more because it may not always have a SrcOp given to it. llvm-svn: 356396
* [GlobalISel] Allow MachineIRBuilder to build subregister copies.Amara Emerson2019-03-151-5/+5
| | | | | | | | | | | | This relaxes some asserts about sizes, and adds an optional subreg parameter to buildCopy(). Also update AArch64 instruction selector to use this in places where we previously used MachineInstrBuilder manually. Differential Revision: https://reviews.llvm.org/D59434 llvm-svn: 356304
* GlobalISel: Use multiple returns for intrinsic structsMatt Arsenault2019-03-141-3/+3
| | | | | | | | | | | This is consistent with what SelectionDAG does and is much easier to work with than the extract sequence with an artificial wide register. For the AMDGPU control flow intrinsics, this was producing an s128 for the i64, i1 tuple return. Any legalization that should apply to a real s128 value would badly obscure the direct values that need to be seen. llvm-svn: 356147
* [MIPS GlobalISel] NarrowScalar G_MULPetar Avramovic2019-03-111-0/+7
| | | | | | | | | | | | | Narrow Scalar G_MUL for MIPS32. Revisit NarrowScalar implementation in LegalizerHelper. Introduce new helper function multiplyRegisters. It performs generic multiplication of values held in multiple registers. Generated instructions use only types NarrowTy and i1. Destination can be same or two times size of the source. Differential Revision: https://reviews.llvm.org/D58824 llvm-svn: 355814
* GlobalISel: Make buildExtract use DstOp/SrcOpMatt Arsenault2019-02-181-12/+15
| | | | llvm-svn: 354292
* GlobalISel: Implement narrowScalar for shift main typeMatt Arsenault2019-02-071-4/+18
| | | | | | | | | | | | | | | This is pretty much directly ported from SelectionDAG. Doesn't include the shift by non-constant but known bits version, since there isn't a globalisel version of computeKnownBits yet. This shows a disadvantage of targets not specifically which type should be used for the shift amount. If type 0 is legalized before type 1, the operations on the shift amount type use the wider type (which are also less likely to legalize). This can be avoided by targets specifying legalization actions on type 1 earlier than for type 0. llvm-svn: 353455
* GlobalISel: Fix CSE handling of buildConstantMatt Arsenault2019-02-041-40/+38
| | | | | | | | | | | | | | | | This fixes two problems with CSE done in buildConstant. First, this would hit an assert when used with a vector result type. Solve this by allowing CSE on the vector elements, but not on the result vector for now. Second, this was also performing the CSE based on the input ConstantInt pointer. The underlying buildConstant could potentially convert the constant depending on the result type, giving in a different ConstantInt*. Stop allowing the APInt and ConstantInt forms from automatically casting to the result type to avoid any similar problems in the future. llvm-svn: 353077
* GlobalISel: Use appropriate extension for legalizing select conditionsMatt Arsenault2019-01-301-0/+20
| | | | llvm-svn: 352597
* GlobalISel: Fix typo in assert messagesMatt Arsenault2019-01-271-2/+2
| | | | llvm-svn: 352301
* GlobalISel: Make buildConstant handle vectorsMatt Arsenault2019-01-221-4/+38
| | | | | | | Produce a splat build_vector similar to how SelectionDAG::getConstant does. llvm-svn: 351880
* GlobalISel: Disallow vectors for G_CONSTANT/G_FCONSTANTMatt Arsenault2019-01-221-4/+2
| | | | llvm-svn: 351853
* 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
* [GISel]: Add support for CSEing continuously during GISel passes.Aditya Nandakumar2019-01-161-0/+2
| | | | | | | | | | https://reviews.llvm.org/D52803 This patch adds support to continuously CSE instructions during each of the GISel passes. It consists of a GISelCSEInfo analysis pass that can be used by the CSEMIRBuilder. llvm-svn: 351283
* [GISel] Add parentheses to an assert because gcc is mean.Craig Topper2018-12-111-1/+1
| | | | llvm-svn: 348900
* [GISel]: Add MachineIRBuilder support for passing in Flags while buildingAditya Nandakumar2018-12-111-1/+4
| | | | | | | | | | | | https://reviews.llvm.org/D55516 Add the ability to pass in flags to buildInstr calls. Currently no validation is performed but that can be easily performed based on the opcode (if necessary). Reviewed by: paquette. llvm-svn: 348893
* [GISel]: Refactor MachineIRBuilder to allow passing additional parameters to ↵Aditya Nandakumar2018-12-111-368/+457
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | build Instrs https://reviews.llvm.org/D55294 Previously MachineIRBuilder::buildInstr used to accept variadic arguments for sources (which were either unsigned or MachineInstrBuilder). While this worked well in common cases, it doesn't allow us to build instructions that have multiple destinations. Additionally passing in other optional parameters in the end (such as flags) is not possible trivially. Also a trivial call such as B.buildInstr(Opc, Reg1, Reg2, Reg3) can be interpreted differently based on the opcode (2defs + 1 src for unmerge vs 1 def + 2srcs). This patch refactors the buildInstr to buildInstr(Opc, ArrayRef<DstOps>, ArrayRef<SrcOps>) where DstOps and SrcOps are typed unions that know how to add itself to MachineInstrBuilder. After this patch, most invocations would look like B.buildInstr(Opc, {s32, DstReg}, {SrcRegs..., SrcMIBs..}); Now all the other calls (such as buildAdd, buildSub etc) forward to buildInstr. It also makes it possible to build instructions with multiple defs. Additionally in a subsequent patch, we should make it possible to add flags directly while building instructions. Additionally, the main buildInstr method is now virtual and other builders now only have to override buildInstr (for say constant folding/cseing) is straightforward. Also attached here (https://reviews.llvm.org/F7675680) is a clang-tidy patch that should upgrade the API calls if necessary. llvm-svn: 348815
* [GlobalISel] Restrict G_MERGE_VALUES capability and replace with new opcodes.Amara Emerson2018-12-101-0/+4
| | | | | | | | | | | | This patch restricts the capability of G_MERGE_VALUES, and uses the new G_BUILD_VECTOR and G_CONCAT_VECTORS opcodes instead in the appropriate places. This patch also includes AArch64 support for selecting G_BUILD_VECTOR of <4 x s32> and <2 x s64> vectors. Differential Revisions: https://reviews.llvm.org/D53629 llvm-svn: 348788
* [GlobalISel] Introduce G_BUILD_VECTOR, G_BUILD_VECTOR_TRUNC and ↵Amara Emerson2018-12-051-0/+58
| | | | | | | | | | | | | | | | | | | | | | | G_CONCAT_VECTOR opcodes. These opcodes are intended to subsume some of the capability of G_MERGE_VALUES, as it was too powerful and thus complex to add deal with throughout the GISel pipeline. G_BUILD_VECTOR creates a vector value from a sequence of uniformly typed scalar values. G_BUILD_VECTOR_TRUNC is a special opcode for handling scalar operands which are larger than the destination vector element type, and therefore does an implicit truncate. G_CONCAT_VECTOR creates a vector by concatenating smaller, uniformly typed, vectors together. These will be used in a subsequent commit. This commit just adds the initial infrastructure. Differential Revision: https://reviews.llvm.org/D53594 llvm-svn: 348430
* [GISel]: Provide standard interface to observe changes in GISel passesAditya Nandakumar2018-12-051-9/+7
| | | | | | | | | | | | | https://reviews.llvm.org/D54980 This provides a standard API across GISel passes to observe and notify passes about changes (insertions/deletions/mutations) to MachineInstrs. This patch also removes the recordInsertion method in MachineIRBuilder and instead provides method to setObserver. Reviewed by: vkeles. llvm-svn: 348406
* [DebugInfo] Generate DWARF debug information for labels. (Fix leak problems)Hsiangkai Wang2018-08-171-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two forms for label debug information in DWARF format. 1. Labels in a non-inlined function: DW_TAG_label DW_AT_name DW_AT_decl_file DW_AT_decl_line DW_AT_low_pc 2. Labels in an inlined function: DW_TAG_label DW_AT_abstract_origin DW_AT_low_pc We will collect label information from DBG_LABEL. Before every DBG_LABEL, we will generate a temporary symbol to denote the location of the label. The symbol could be used to get DW_AT_low_pc afterwards. So, we create a mapping between 'inlined label' and DBG_LABEL MachineInstr in DebugHandlerBase. The DBG_LABEL in the mapping is used to query the symbol before it. The AbstractLabels in DwarfCompileUnit is used to process labels in inlined functions. We also keep a mapping between scope and labels in DwarfFile to help to generate correct tree structure of DIEs. It also generates label debug information under global isel. Differential Revision: https://reviews.llvm.org/D45556 llvm-svn: 340039
* Revert "[DebugInfo] Generate DWARF debug information for labels. (Fix leak ↵Bruno Cardoso Lopes2018-08-141-9/+0
| | | | | | | | | | | | problems)" This reverts commit cb8c5e417d55141f3f079a8a876e786f44308336 / r339676. This causing a test to fail in http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/48406/ LLVM :: DebugInfo/Generic/debug-label.ll llvm-svn: 339700
* [DebugInfo] Generate DWARF debug information for labels. (Fix leak problems)Hsiangkai Wang2018-08-141-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two forms for label debug information in DWARF format. 1. Labels in a non-inlined function: DW_TAG_label DW_AT_name DW_AT_decl_file DW_AT_decl_line DW_AT_low_pc 2. Labels in an inlined function: DW_TAG_label DW_AT_abstract_origin DW_AT_low_pc We will collect label information from DBG_LABEL. Before every DBG_LABEL, we will generate a temporary symbol to denote the location of the label. The symbol could be used to get DW_AT_low_pc afterwards. So, we create a mapping between 'inlined label' and DBG_LABEL MachineInstr in DebugHandlerBase. The DBG_LABEL in the mapping is used to query the symbol before it. The AbstractLabels in DwarfCompileUnit is used to process labels in inlined functions. We also keep a mapping between scope and labels in DwarfFile to help to generate correct tree structure of DIEs. It also generates label debug information under global isel. Differential Revision: https://reviews.llvm.org/D45556 llvm-svn: 339676
* Revert "[DebugInfo] Generate DWARF debug information for labels."Vlad Tsyrklevich2018-07-311-9/+0
| | | | | | | This reverts commits r338390 and r338398, they were causing LSan failures on the ASan bot. llvm-svn: 338408
* [DebugInfo] Generate DWARF debug information for labels.Hsiangkai Wang2018-07-311-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two forms for label debug information in DWARF format. 1. Labels in a non-inlined function: DW_TAG_label DW_AT_name DW_AT_decl_file DW_AT_decl_line DW_AT_low_pc 2. Labels in an inlined function: DW_TAG_label DW_AT_abstract_origin DW_AT_low_pc We will collect label information from DBG_LABEL. Before every DBG_LABEL, we will generate a temporary symbol to denote the location of the label. The symbol could be used to get DW_AT_low_pc afterwards. So, we create a mapping between 'inlined label' and DBG_LABEL MachineInstr in DebugHandlerBase. The DBG_LABEL in the mapping is used to query the symbol before it. The AbstractLabels in DwarfCompileUnit is used to process labels in inlined functions. We also keep a mapping between scope and labels in DwarfFile to help to generate correct tree structure of DIEs. It also generates label debug information under global isel. Differential Revision: https://reviews.llvm.org/D45556 llvm-svn: 338390
* [GlobalISel] Add a G_BLOCK_ADDR opcode to handle IR blockaddress constants.Amara Emerson2018-07-311-0/+9
| | | | | | Differential Revision: https://reviews.llvm.org/D49900 llvm-svn: 338335
* [globalisel][irtranslator] Add support for atomicrmw and (strong) cmpxchgDaniel Sanders2018-07-091-1/+116
| | | | | | | | | | | | | | | | | | | | Summary: This patch adds support for the atomicrmw instructions and the strong cmpxchg instruction to the IRTranslator. I've left out weak cmpxchg because LangRef.rst isn't entirely clear on what difference it makes to the backend. As far as I can tell from the code, it only matters to AtomicExpandPass which is run at the LLVM-IR level. Reviewers: ab, t.p.northover, qcolombet, rovka, aditya_nandakumar, volkan, javed.absar Reviewed By: qcolombet Subscribers: kristof.beyls, javed.absar, igorb, llvm-commits Differential Revision: https://reviews.llvm.org/D40092 llvm-svn: 336589
* Reapplying r331819 [GlobalISel][Legalizer] More concise and faster ↵Roman Tereshin2018-05-091-2/+6
| | | | | | | | | widenScalar, NFC The commit was a suspect for clang-cmake-aarch64-global-isel and clang-cmake-aarch64-quick bot failures, proved to be innocent. llvm-svn: 331898
* Revert r331819 [GlobalISel][Legalizer] More concise and faster widenScalar, NFCRoman Tereshin2018-05-091-6/+2
| | | | | | | Reverting this to see if the clang-cmake-aarch64-global-isel and clang-cmake-aarch64-quick bots are failing because of this commit llvm-svn: 331839
* [GlobalISel][Legalizer] More concise and faster widenScalar, NFCRoman Tereshin2018-05-081-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Refactoring LegalizerHelper::widenScalar member function reducing its size by approximately a factor of 2 and (hopefuly) making it more straightforward and regular by introducing widenScalarSrc and widenScalarDst helper methods. The new widenScalar* methods mutate the instructions in place instead of recreating them from scratch and removing the originals. The compile time implications of this were measured on sqlite3 amalgamation, targeting AArch64 in -O0: LegalizerHelper::widenScalar: > 25% faster Legalizer::runOnMachineFunction: ~ 4.0 - 4.5% faster Also adding MachineOperand::setCImm and refactoring out MachineIRBuilder::recordInsertion methods to make the change possible. Reviewers: aditya_nandakumar, bogner, javed.absar, t.p.northover, ab, dsanders, arsenm Reviewed By: aditya_nandakumar Subscribers: wdng, rovka, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D46414 llvm-svn: 331819
* [globalisel][legalizerinfo] Introduce dedicated extending loads and add ↵Daniel Sanders2018-04-281-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lowerings for them Summary: Previously, a extending load was represented at (G_*EXT (G_LOAD x)). This had a few drawbacks: * G_LOAD had to be legal for all sizes you could extend from, even if registers didn't naturally hold those sizes. * All sizes you could extend from had to be allocatable just in case the extend went missing (e.g. by optimization). * At minimum, G_*EXT and G_TRUNC had to be legal for these sizes. As we improve optimization of extends and truncates, this legality requirement would spread without considerable care w.r.t when certain combines were permitted. * The SelectionDAG importer required some ugly and fragile pattern rewriting to translate patterns into this style. This patch begins changing the representation to: * (G_[SZ]EXTLOAD x) * (G_LOAD x) any-extends when MMO.getSize() * 8 < ResultTy.getSizeInBits() which resolves these issues by allowing targets to work entirely in their native register sizes, and by having a more direct translation from SelectionDAG patterns. This patch introduces the new generic instructions and new variation on G_LOAD and adds lowering for them to convert back to the existing representations. Depends on D45466 Reviewers: ab, aditya_nandakumar, bogner, rtereshin, volkan, rovka, aemerson, javed.absar Reviewed By: aemerson Subscribers: aemerson, kristof.beyls, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D45540 llvm-svn: 331115
* [GISel] Refactor MachineIRBuilder to allow transformations whileAditya Nandakumar2018-04-091-257/+250
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | building. https://reviews.llvm.org/D45067 This change attempts to do two things: 1) It separates out the state that is stored in the MachineIRBuilder(InsertionPt, MF, MRI, InsertFunction etc) into a separate object called MachineIRBuilderState. 2) Add the ability to constant fold operations while building instructions (optionally). MachineIRBuilder is now refactored into a MachineIRBuilderBase which contains lots of non foldable build methods and their implementation. Instructions which can be constant folded/transformed are now in a class called FoldableInstructionBuilder which uses CRTP to use the implementation of the derived class for buildBinaryOps. Additionally buildInstr in the derived class can be used to implement other kinds of transformations. Also because of separation of state, given a MachineIRBuilder in an API, if one wishes to use another MachineIRBuilder, a new one can be constructed from the state locally. For eg, void doFoo(MachineIRBuilder &B) { MyCustomBuilder CustomB(B.getState()); // Use CustomB for building. } reviewed by : aemerson llvm-svn: 329596
* [GISel]: Add helpers for easy building G_FCONSTANT along with matchersAditya Nandakumar2018-03-091-0/+8
| | | | | | | | | | | | | | | | | | Added helpers to build G_FCONSTANT, along with matching ConstantFP and unit tests for the same. Sample usage. auto MIB = Builder.buildFConstant(s32, 0.5); // Build IEEESingle For Matching the above const ConstantFP* Tmp; mi_match(DstReg, MRI, m_GFCst(Tmp)); https://reviews.llvm.org/D44128 reviewed by: volkan llvm-svn: 327152
* 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
* Revert r319691: [globalisel][tablegen] Split atomic load/store into separate ↵Daniel Sanders2017-12-051-32/+0
| | | | | | | | opcode and enable for AArch64. Some concerns were raised with the direction. Revert while we discuss it and look into an alternative llvm-svn: 319739
* [globalisel][tablegen] Split atomic load/store into separate opcode and ↵Daniel Sanders2017-12-041-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | enable for AArch64. This patch splits atomics out of the generic G_LOAD/G_STORE and into their own G_ATOMIC_LOAD/G_ATOMIC_STORE. This is a pragmatic decision rather than a necessary one. Atomic load/store has little in implementation in common with non-atomic load/store. They tend to be handled very differently throughout the backend. It also has the nice side-effect of slightly improving the common-case performance at ISel since there's no longer a need for an atomicity check in the matcher table. All targets have been updated to remove the atomic load/store check from the G_LOAD/G_STORE path. AArch64 has also been updated to mark G_ATOMIC_LOAD/G_ATOMIC_STORE legal. There is one issue with this patch though which also affects the extending loads and truncating stores. The rules only match when an appropriate G_ANYEXT is present in the MIR. For example, (G_ATOMIC_STORE (G_TRUNC:s16 (G_ANYEXT:s32 (G_ATOMIC_LOAD:s16 X)))) will match but: (G_ATOMIC_STORE (G_ATOMIC_LOAD:s16 X)) will not. This shouldn't be a problem at the moment, but as we get better at eliminating extends/truncates we'll likely start failing to match in some cases. The current plan is to fix this in a patch that changes the representation of extending-load/truncating-store to allow the MMO to describe a different type to the operation. llvm-svn: 319691
* [aarch64][globalisel] Legalize G_ATOMIC_CMPXCHG_WITH_SUCCESS and G_ATOMICRMW_*Daniel Sanders2017-11-301-0/+25
| | | | | | | | | | | G_ATOMICRMW_* is generally legal on AArch64. The exception is G_ATOMICRMW_NAND. G_ATOMIC_CMPXCHG_WITH_SUCCESS needs to be lowered to G_ATOMIC_CMPXCHG with an external comparison. Note that IRTranslator doesn't generate these instructions yet. llvm-svn: 319466
* 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-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
* [GISel]: Implement widenScalar for Legalizing G_PHIAditya Nandakumar2017-08-251-14/+16
| | | | | | https://reviews.llvm.org/D37018 llvm-svn: 311763
* Use helper function instead of manually constructing DBG_VALUEs (NFC)Adrian Prantl2017-08-011-12/+7
| | | | | | rdar://problem/33580047 llvm-svn: 309757
* Remove the unused DBG_VALUE offset parameter from GlobalISel (NFC)Adrian Prantl2017-07-281-5/+5
| | | | | | | Followup to r309426. rdar://problem/33580047 llvm-svn: 309449
* [MachineIRBuilder] Fix formatting. NFC.Diana Picus2017-07-051-1/+1
| | | | llvm-svn: 307144
* [MachineIRBuilder] Add buildOr helper. NFC.Diana Picus2017-07-051-0/+4
| | | | | | This isn't used anywhere yet, but I need it for a future commit. llvm-svn: 307141
* [MachineIRBuilder] Add buildBinaryOp helper. NFCDiana Picus2017-07-051-29/+11
| | | | | | | Add a helper for building simple binary ops like add, mul, sub, and. This can be used in the future for quickly adding support for or, xor. llvm-svn: 307139
* GlobalISel: add G_IMPLICIT_DEF instruction.Tim Northover2017-06-301-1/+1
| | | | | | | | | It looks like there are two target-independent but not GISel instructions that need legalization, IMPLICIT_DEF and PHI. These are already anomalies since their operands have important LLTs attached, so to make things more uniform it seems like a good idea to add generic variants. Starting with G_IMPLICIT_DEF. llvm-svn: 306875
* GlobalISel: add some more sanity-checking to MachineInstrBuilder. NFC.Tim Northover2017-06-271-1/+15
| | | | llvm-svn: 306481
* GlobalISel: verify that a COPY is trivial when created.Tim Northover2017-06-271-2/+3
| | | | | | | | | | | | Without this check, COPY instructions can actually be one of the generic casts in disguise. That's confusing and bad. At some point during ISel this restriction has to be relaxed since the fully selected instructions will usually use COPY for those purposes. Right now I think it's possible that relaxation occurs during RegBankSelect (hence the change there). I'm not convinced that's where it belongs long-term though. llvm-svn: 306470
* AArch64: legalize G_EXTRACT operations.Tim Northover2017-06-261-0/+3
| | | | | | | This is the dual problem to legalizing G_INSERTs so most of the code and testing was cribbed from there. llvm-svn: 306328
* GlobalISel: convert buildSequence to use non-deprecated instructions.Tim Northover2017-06-231-9/+25
| | | | | | | | G_SEQUENCE is going away soon so as a first step the MachineIRBuilder needs to be taught how to emulate it with alternatives. We use G_MERGE_VALUES where possible, and a sequence of G_INSERTs if not. llvm-svn: 306119
OpenPOWER on IntegriCloud