summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/GlobalISel/RegisterBankInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* unique_ptrify some containers in GlobalISel::RegisterBankInfoDavid Blaikie2017-01-301-19/+9
| | | | | | | | | To simplify/clarify memory ownership, make leaks (as one was found/fixed recently) harder to write, etc. (also, while I was there - removed a duplicate lookup in a container) llvm-svn: 293506
* [RegisterBankInfo] Emit proper type for remapped registers.Quentin Colombet2017-01-281-3/+25
| | | | | | | | | | | | | | | | When the OperandsMapper creates virtual registers, it used to just create plain scalar register with the right size. This may confuse the instruction selector because we lose the information of the instruction using those registers what supposed to do. The MachineVerifier complains about that already. With this patch, the OperandsMapper still creates plain scalar register, but the expectation is for the mapping function to remap the type properly. The default mapping function has been updated to do that. rdar://problem/30231850 llvm-svn: 293362
* Cleanup dump() functions.Matthias Braun2017-01-281-0/+8
| | | | | | | | | | | | | | | | | | 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
* Fix memory leak in globalisel.Evgeniy Stepanov2017-01-281-0/+2
| | | | | | | | | | | | | | | | |     #0 0x89cdeb in operator new[](unsigned long) /code/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:84:37     #1 0x4ec87c4 in llvm::RegisterBankInfo::ValueMapping const* llvm::RegisterBankInfo::getOperandsMapping<llvm::RegisterBankInfo::ValueMapping const* const*>(llvm::RegisterBankInfo::ValueMapping const* const*, llvm::RegisterBankInfo::ValueMapping const* const*) const /code/llvm/lib/CodeGen/GlobalISel/RegisterBankInfo.cpp:297:9     #2 0x9327ee in llvm::AArch64RegisterBankInfo::getInstrMapping(llvm::MachineInstr const&) const /code/llvm/lib/Target/AArch64/AArch64RegisterBankInfo.cpp:540:30     #3 0x4eb8d07 in llvm::RegBankSelect::assignInstr(llvm::MachineInstr&) /code/llvm/lib/CodeGen/GlobalISel/RegBankSelect.cpp:546:24     #4 0x4eb9dd2 in llvm::RegBankSelect::runOnMachineFunction(llvm::MachineFunction&) /code/llvm/lib/CodeGen/GlobalISel/RegBankSelect.cpp:624:12     #5 0x3141875 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) /code/llvm/lib/CodeGen/MachineFunctionPass.cpp:62:13     #6 0x396128d in llvm::FPPassManager::runOnFunction(llvm::Function&) /code/llvm/lib/IR/LegacyPassManager.cpp:1513:27     #7 0x3961832 in llvm::FPPassManager::runOnModule(llvm::Module&) /code/llvm/lib/IR/LegacyPassManager.cpp:1534:16     #8 0x3962540 in runOnModule /code/llvm/lib/IR/LegacyPassManager.cpp:1590:27     #9 0x3962540 in llvm::legacy::PassManagerImpl::run(llvm::Module&) /code/llvm/lib/IR/LegacyPassManager.cpp:1693     #10 0x8ae368 in compileModule(char**, llvm::LLVMContext&) /code/llvm/tools/llc/llc.cpp:562:8     #11 0x8a7a1b in main /code/llvm/tools/llc/llc.cpp:316:22 llvm-svn: 293351
* [globalisel] Move as much RegisterBank initialization to the constructor as ↵Daniel Sanders2017-01-121-12/+3
| | | | | | | | | | | | | | | | | | | | | possible Summary: The register bank is now entirely initialized in the constructor. However, we still have the hardcoded number of register classes which will be dealt with in the TableGen patch (D27338) since we do not have access to this information to resolve this at this stage. The number of register classes is known to the TRI and to TableGen but the RegisterBank constructor is too early for the former and too late for the latter. This will be fixed when the data is tablegen-erated. Reviewers: t.p.northover, ab, rovka, qcolombet Subscribers: aditya_nandakumar, kristof.beyls, vkalintiris, llvm-commits, dberris Differential Revision: https://reviews.llvm.org/D27809 llvm-svn: 291770
* [globalisel] Initialize RegisterBanks with static data.Daniel Sanders2017-01-121-100/+8
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Refactor the RegisterBank initialization to use static data. This requires GlobalISel implementations to rewrite calls to createRegisterBank() and addRegBankCoverage() into a call to setRegBankData(). Out of tree targets can use diff 4 of D27807 (https://reviews.llvm.org/D27807?id=84117) to have addRegBankCoverage() dump the register classes and other data that needs to be provided to setRegBankData(). This is the method that was used to generate the static data in this patch. Tablegen-eration of this static data will follow after some refactoring. Reviewers: t.p.northover, ab, rovka, qcolombet Subscribers: aditya_nandakumar, kristof.beyls, vkalintiris, llvm-commits, dberris Differential Revision: https://reviews.llvm.org/D27807 Differential Revision: https://reviews.llvm.org/D27808 llvm-svn: 291768
* GlobalISel: only print debug info with -debug. NFC.Tim Northover2017-01-111-1/+1
| | | | | | Turns out DEBUG(...) has uses even inside NDEBUG checks. llvm-svn: 291685
* [globalisel] Stop requiring -debug/-debug-only=registerbankinfo for assertions.Daniel Sanders2017-01-061-6/+7
| | | | | | | | | | | | | | | | | | | | | Summary: I've noticed that these assertions don't trigger when the condition is false. The problem is that the DEBUG(x) macro only executes x when the pass is emitting debug output via the -debug and -debug-only=registerbankinfo command line arguments. Debug builds should always execute the assertions so use '#ifndef NDEBUG' instead. Also removed an assertion that is only true the first time it's tested. <Target>RegisterBankInfo's constructor will re-use register banks causing them to be valid on subsequent tests. That assertion will fail on the first test too in the near future. Reviewers: t.p.northover, ab, rovka, qcolombet Subscribers: dberris, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D28358 llvm-svn: 291235
* [RegisterBankInfo] Allow to set a register class when nothing else is setQuentin Colombet2016-12-221-3/+2
| | | | | | | | This is going to be needed to be able to constraint register class on target specific instruction while the RegBankSelect pass did not run yet. llvm-svn: 290375
* GlobalISel: Fix indentation. NFCDiana Picus2016-11-141-3/+3
| | | | llvm-svn: 286808
* GlobalISel: fix typo. NFCTim Northover2016-11-091-2/+2
| | | | llvm-svn: 286408
* [RegisterBankInfo] Change the default mapping for Copy and PHI.Quentin Colombet2016-09-291-52/+35
| | | | | | | | | | | | | | Instead of producing a mapping for all the operands, we only generate a mapping for the definition. Indeed, the other operands are not constrained by the instruction and thus, we should leave the choice to the actual definition to do the right thing. In pratice this is almost NFC, but with one advantage. We will have only one instance of OperandsMapping for each copy and phi that map to one register bank instead of one different instance for each different number of operands for each copy and phi. llvm-svn: 282756
* [RegisterBankInfo] Uniquely generate OperandsMapping.Quentin Colombet2016-09-281-8/+63
| | | | | | | | | | | This is a step toward statically allocate InstructionMapping. Like the previous few commits, the goal is to move toward a TableGen'ed like structure with no dynamic allocation at all. This should already improve compile time by getting rid of a bunch of memmove of SmallVectors. llvm-svn: 282643
* [RegisterBankInfo] Rework the APIs of ValueMapping.Quentin Colombet2016-09-281-10/+12
| | | | | | | This is a preparatory commit for more TableGen-like structure. NFC llvm-svn: 282642
* [RegisterBankInfo] Constify the member of the XXXMapping maps.Quentin Colombet2016-09-241-2/+2
| | | | | | | This makes it obvious that items in those maps behave like statically created objects. llvm-svn: 282327
* [RegisterBankInfo] Add statistics for dynamic value mappings.Quentin Colombet2016-09-241-0/+8
| | | | | | | Like partial mappings, as we move toward TableGen'ed information, the number should reach zero eventually. llvm-svn: 282325
* [RegisterBankInfo] Uniquely generate ValueMapping.Quentin Colombet2016-09-241-11/+52
| | | | | | | | This is a step toward statically allocate ValueMapping. Like the previous few commits, the goal is to move toward a TableGen'ed like structure with no dynamic allocation at all. llvm-svn: 282324
* [RegisterBankInfo] Keep valid pointers for PartialMappings.Quentin Colombet2016-09-241-4/+9
| | | | | | | | | | | | | | | Previously we were using the address of the unique instance of a partial mapping in the related map to access this instance. However, when the map grows, the whole set of instances may be moved elsewhere and the previous addresses are not valid anymore. Instead, keep the address of the unique heap allocated instance of a partial mapping. Note: I did not see any actual bugs for that problem as the number of partial mappings dynamically allocated is small (<= 4). llvm-svn: 282323
* [RegisterBankInfo] Add statistics for dynamic partial mappings.Quentin Colombet2016-09-231-0/+11
| | | | | | | | Collect statistics about the number of partial mappings dynamically allocated and accessed. Ultimately, when the whole TableGen infrastructure is set, those numbers should be zero. llvm-svn: 282274
* [RegisterBankInfo] Mark the dump methods with LLVM_DUMP_METHOD.Quentin Colombet2016-09-231-4/+4
| | | | | | NFC llvm-svn: 282221
* [RegisterBankInfo] Check that the mapping covers the interesting bits.Quentin Colombet2016-09-231-2/+3
| | | | | | | | | | | | | | | In the verify method of the ValueMapping class we used to check that the mapping exactly matches the bits of the input value. This is problematic for statically allocated mappings because we would need a different mapping for each different size of the value that maps on one instruction. For instance, with such scheme, we would need a different mapping for a value of size 1, 5, 23 whereas they all end up on a 32-bit wide instruction. Therefore, change the verifier to check that the meaningful bits are covered by the mapping instead of matching them. llvm-svn: 282214
* [RegisterBankInfo] Use array instead of SmallVector for BreakDown.Quentin Colombet2016-09-231-32/+34
| | | | | | | | | | | | | This is another step toward TableGen'ed like structures. The BreakDown of the mapping of the value will be statically computed by TableGen, thus we only have to point to the right entry in the table instead of dynamically allocate the mapping for each instruction. We still support the dynamic allocation through a factory of PartialMapping to ease the bring-up of the targets while the TableGen backend is not available. llvm-svn: 282213
* [RegisterBankInfo] Move to statically allocated RegisterBank.Quentin Colombet2016-09-221-3/+8
| | | | | | | | | | | | This commit is basically the first step toward what will RegisterBankInfo look when it gets TableGen'ed. It introduces a XXXGenRegisterBankInfo.def file that is what TableGen will issue at some point. Moreover, the RegBanks field in RegisterBankInfo changed to reflect the static (compile time) aspect of the information. llvm-svn: 282131
* [RegisterBankInfo] Take advantage of the extra argument of SmallVector::resize.Quentin Colombet2016-09-221-3/+1
| | | | | | | | When initializing an instance of OperandsMapper, instead of using SmallVector::resize followed by std::fill, use the function that directly does that in SmallVector. llvm-svn: 282130
* [RegisterBankInfo] Adapt call to std::fill due to use of SmallVector.Quentin Colombet2016-09-191-1/+1
| | | | | | This was meant to be commited with my previous commit. llvm-svn: 281948
* [RegisterBankInfo] Avoid heap allocation in most cases.Quentin Colombet2016-09-191-1/+1
| | | | | | | | | | | The OperandsMapper class is used heavy in RegBankSelect and each instantiation triggered a heap allocation for the array of operands. Instead, use a SmallVector with a big enough size such that most of the cases do not have to use dynamically allocated memory. This improves the compile time of the RegBankSelect pass. llvm-svn: 281916
* [AArch64][GlobalISel] Test default regbank mapping for G_ICMP.Ahmed Bougacha2016-09-161-1/+1
| | | | | | | Also relax a RegisterBankInfo verifier check that's incompatible with 1-bit mappings. llvm-svn: 281735
* GlobalISel: remove "unsized" LLTTim Northover2016-09-151-1/+1
| | | | | | | | It was only really there as a sentinel when instructions had to have precisely one type. Now that registers are typed, each register really has to have a type that is sized. llvm-svn: 281599
* GlobalISel: remove G_TYPE and G_PHITim Northover2016-09-091-2/+1
| | | | | | | | These instructions were only necessary when type information was stored in the MachineInstr (because only generic MachineInstrs possessed a type). Now that it's in MachineRegisterInfo, COPY and PHI work fine. llvm-svn: 281037
* GlobalISel: move type information to MachineRegisterInfo.Tim Northover2016-09-091-2/+3
| | | | | | | | | | | | | | | | | 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
* GlobalISel: use G_TYPE to annotate physregs with a type.Tim Northover2016-08-311-1/+2
| | | | | | | | | | More preparation for dropping source types from MachineInstrs: regsters coming out of already-selected code (i.e. non-generic instructions) don't have a type, but that information is needed so we must add it manually. This is done via a new G_TYPE instruction. llvm-svn: 280292
* [GlobalISel] Introduce an instruction selector.Ahmed Bougacha2016-07-271-0/+19
| | | | | | | | And implement it for AArch64, supporting x/w ADD/OR. Differential Revision: https://reviews.llvm.org/D22373 llvm-svn: 276875
* GlobalISel: implement low-level type with just size & vector lanes.Tim Northover2016-07-201-33/+13
| | | | | | | | This should be all the low-level instruction selection needs to determine how to implement an operation, with the remaining context taken from the opcode (e.g. G_ADD vs G_FADD) or other flags not based on type (e.g. fast-math). llvm-svn: 276158
* [GlobalISel] Simplify more RegClassOrRegBank is+get. NFC.Ahmed Bougacha2016-07-191-5/+3
| | | | llvm-svn: 276011
* [GlobalISel] Fix #include ordering/spacing. NFC.Ahmed Bougacha2016-07-141-2/+2
| | | | llvm-svn: 275423
* [RegisterBankInfo] Avoid code duplication in OperandsMapper for the ↵Quentin Colombet2016-06-081-6/+17
| | | | | | | | | | | | | computation of the end of range. Refactor the code so that we do not compute in two different places the end iterator for the range of new virtual registers for a given operand. Although this refactoring was intended as NFC, this is not the case because it actually fixes a bug where we were returning a range off by 1 (too long). Right now, this could not result in an actual bug because we were accessing this range via the BreakDown size of the related operand. llvm-svn: 272208
* [RegisterBankInfo] Add dump/print methods for OperandsMapper.Quentin Colombet2016-06-081-2/+55
| | | | | | Improve debuggability of the OperandsMapper helper class. llvm-svn: 272207
* [RegisterBankInfo] Implement the method to apply a mapping.Quentin Colombet2016-06-081-0/+27
| | | | | | | | | Now, the target will be able to provide its how implementation to remap an instruction. This open the way to crazier optimizations, but to beginning with, we will be able to handle something else than the default mapping. llvm-svn: 272165
* [RegisterBankInfo] Introduce OperandsMapper class.Quentin Colombet2016-06-081-0/+90
| | | | | | | This helper class is used to encapsulate the necessary information to remap an instruction. llvm-svn: 272161
* [RegisterBankInfo] Move a hidden function into a static method. NFC.Quentin Colombet2016-06-081-24/+22
| | | | | | This will allow code reuse in the coming commits. llvm-svn: 272083
* Fix -Wunused-variable in non-asserts build.Eric Liu2016-04-221-0/+1
| | | | llvm-svn: 267128
* Fix more -Wunused-variable in non-asserts build.David Blaikie2016-04-211-3/+2
| | | | llvm-svn: 267077
* Fix some -Wunused-variable warnings in non-asserts builds.David Blaikie2016-04-211-5/+6
| | | | llvm-svn: 267073
* [RegisterBankInfo] Change the API for the verify methods.Quentin Colombet2016-04-211-8/+12
| | | | | | | Return bool instead of void so that it is natural to put the calls into asserts. llvm-svn: 267033
* [RegisterBankInfo] Change the representation of the partial mappings.Quentin Colombet2016-04-211-30/+24
| | | | | | | | | Instead of holding a mask, hold two value: the start index and the length of the mapping. This is a more compact representation, although less powerful. That being said, arbitrary masks would not have worked for the generic so do not allow them in the first place. llvm-svn: 267025
* [RegisterBankInfo] Do not provide a default mapping for non-reg of phiQuentin Colombet2016-04-121-0/+7
| | | | | | operations. llvm-svn: 266027
* [RegisterBankInfo] Change the implementation for the default mapping.Quentin Colombet2016-04-081-1/+14
| | | | | | | | | | Do not give that much importance to the current register bank of an operand. This is likely just a side effect of the current execution and it is properly wise to prefer a register bank that can be extracted from the information available statically (like encoding constraints and type). llvm-svn: 265810
* [RegisterBankInfo] Make the debug output more compact.Quentin Colombet2016-04-081-1/+1
| | | | | | | Print the mask of the partial mapping as an hexadecimal instead of a binary value. llvm-svn: 265754
* [RegisterBankInfo] Add print and dump method to the InstructionMappingQuentin Colombet2016-04-071-0/+16
| | | | | | helper class. llvm-svn: 265747
* [RegisterBankInfo] Add print and dump method to the ValueMapping helperQuentin Colombet2016-04-071-0/+16
| | | | | | class. llvm-svn: 265746
OpenPOWER on IntegriCloud