summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [CodeGen] Move printing MO_CImmediate operands to MachineOperand::printFrancis Visoiu Mistrih2017-12-081-0/+24
| | | | | | | Work towards the unification of MIR and debug output by refactoring the interfaces. llvm-svn: 320140
* [CodeGen] Use MachineOperand::print in the MIRPrinter for MO_Register.Francis Visoiu Mistrih2017-12-071-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Work towards the unification of MIR and debug output by refactoring the interfaces. For MachineOperand::print, keep a simple version that can be easily called from `dump()`, and a more complex one which will be called from both the MIRPrinter and MachineInstr::print. Add extra checks inside MachineOperand for detached operands (operands with getParent() == nullptr). https://reviews.llvm.org/D40836 * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/kill: ([^ ]+) ([^ ]+)<def> ([^ ]+)/kill: \1 def \2 \3/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/kill: ([^ ]+) ([^ ]+) ([^ ]+)<def>/kill: \1 \2 def \3/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/kill: def ([^ ]+) ([^ ]+) ([^ ]+)<def>/kill: def \1 \2 def \3/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/<def>//g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/([^ ]+)<kill>/killed \1/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/([^ ]+)<imp-use,kill>/implicit killed \1/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/([^ ]+)<dead>/dead \1/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/([^ ]+)<def[ ]*,[ ]*dead>/dead \1/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/([^ ]+)<imp-def[ ]*,[ ]*dead>/implicit-def dead \1/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/([^ ]+)<imp-def>/implicit-def \1/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/([^ ]+)<imp-use>/implicit \1/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/([^ ]+)<internal>/internal \1/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/([^ ]+)<undef>/undef \1/g' llvm-svn: 320022
* Fix a bunch more layering of CodeGen headers that are in TargetDavid Blaikie2017-11-172-3/+3
| | | | | | | | 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-2/+2
| | | | | | | | 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
* Silence MSVC error C2398Kristof Beyls2017-11-071-2/+2
| | | | | | | | Reported by http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/6000/steps/build-unified-tree/logs/stdio The error messages were all similar to: llvm\unittests\CodeGen\GlobalISel\LegalizerInfoTest.cpp(54): error C2398: Element '1': conversion from '' to 'unsigned int' requires a narrowing conversion llvm-svn: 317578
* [GlobalISel] Enable legalizing non-power-of-2 sized types.Kristof Beyls2017-11-072-100/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changes the interface of how targets describe how to legalize, see the below description. 1. Interface for targets to describe how to legalize. In GlobalISel, the API in the LegalizerInfo class is the main interface for targets to specify which types are legal for which operations, and what to do to turn illegal type/operation combinations into legal ones. For each operation the type sizes that can be legalized without having to change the size of the type are specified with a call to setAction. This isn't different to how GlobalISel worked before. For example, for a target that supports 32 and 64 bit adds natively: for (auto Ty : {s32, s64}) setAction({G_ADD, 0, s32}, Legal); or for a target that needs a library call for a 32 bit division: setAction({G_SDIV, s32}, Libcall); The main conceptual change to the LegalizerInfo API, is in specifying how to legalize the type sizes for which a change of size is needed. For example, in the above example, how to specify how all types from i1 to i8388607 (apart from s32 and s64 which are legal) need to be legalized and expressed in terms of operations on the available legal sizes (again, i32 and i64 in this case). Before, the implementation only allowed specifying power-of-2-sized types (e.g. setAction({G_ADD, 0, s128}, NarrowScalar). A worse limitation was that if you'd wanted to specify how to legalize all the sized types as allowed by the LLVM-IR LangRef, i1 to i8388607, you'd have to call setAction 8388607-3 times and probably would need a lot of memory to store all of these specifications. Instead, the legalization actions that need to change the size of the type are specified now using a "SizeChangeStrategy". For example: setLegalizeScalarToDifferentSizeStrategy( G_ADD, 0, widenToLargerAndNarrowToLargest); This example indicates that for type sizes for which there is a larger size that can be legalized towards, do it by Widening the size. For example, G_ADD on s17 will be legalized by first doing WidenScalar to make it s32, after which it's legal. The "NarrowToLargest" indicates what to do if there is no larger size that can be legalized towards. E.g. G_ADD on s92 will be legalized by doing NarrowScalar to s64. Another example, taken from the ARM backend is: for (unsigned Op : {G_SDIV, G_UDIV}) { setLegalizeScalarToDifferentSizeStrategy(Op, 0, widenToLargerTypesUnsupportedOtherwise); if (ST.hasDivideInARMMode()) setAction({Op, s32}, Legal); else setAction({Op, s32}, Libcall); } For this example, G_SDIV on s8, on a target without a divide instruction, would be legalized by first doing action (WidenScalar, s32), followed by (Libcall, s32). The same principle is also followed for when the number of vector lanes on vector data types need to be changed, e.g.: setAction({G_ADD, LLT::vector(8, 8)}, LegalizerInfo::Legal); setAction({G_ADD, LLT::vector(16, 8)}, LegalizerInfo::Legal); setAction({G_ADD, LLT::vector(4, 16)}, LegalizerInfo::Legal); setAction({G_ADD, LLT::vector(8, 16)}, LegalizerInfo::Legal); setAction({G_ADD, LLT::vector(2, 32)}, LegalizerInfo::Legal); setAction({G_ADD, LLT::vector(4, 32)}, LegalizerInfo::Legal); setLegalizeVectorElementToDifferentSizeStrategy( G_ADD, 0, widenToLargerTypesUnsupportedOtherwise); As currently implemented here, vector types are legalized by first making the vector element size legal, followed by then making the number of lanes legal. The strategy to follow in the first step is set by a call to setLegalizeVectorElementToDifferentSizeStrategy, see example above. The strategy followed in the second step "moreToWiderTypesAndLessToWidest" (see code for its definition), indicating that vectors are widened to more elements so they map to natively supported vector widths, or when there isn't a legal wider vector, split the vector to map it to the widest vector supported. Therefore, for the above specification, some example legalizations are: * getAction({G_ADD, LLT::vector(3, 3)}) returns {WidenScalar, LLT::vector(3, 8)} * getAction({G_ADD, LLT::vector(3, 8)}) then returns {MoreElements, LLT::vector(8, 8)} * getAction({G_ADD, LLT::vector(20, 8)}) returns {FewerElements, LLT::vector(16, 8)} 2. Key implementation aspects. How to legalize a specific (operation, type index, size) tuple is represented by mapping intervals of integers representing a range of size types to an action to take, e.g.: setScalarAction({G_ADD, LLT:scalar(1)}, {{1, WidenScalar}, // bit sizes [ 1, 31[ {32, Legal}, // bit sizes [32, 33[ {33, WidenScalar}, // bit sizes [33, 64[ {64, Legal}, // bit sizes [64, 65[ {65, NarrowScalar} // bit sizes [65, +inf[ }); Please note that most of the code to do the actual lowering of non-power-of-2 sized types is currently missing, this is just trying to make it possible for targets to specify what is legal, and how non-legal types should be legalized. Probably quite a bit of further work is needed in the actual legalizing and the other passes in GlobalISel to support non-power-of-2 sized types. I hope the documentation in LegalizerInfo.h and the examples provided in the various {Target}LegalizerInfo.cpp and LegalizerInfoTest.cpp explains well enough how this is meant to be used. This drops the need for LLT::{half,double}...Size(). Differential Revision: https://reviews.llvm.org/D30529 llvm-svn: 317560
* Move TargetFrameLowering.h to CodeGen where it's implementedDavid Blaikie2017-11-031-1/+1
| | | | | | | | | | | This header already includes a CodeGen header and is implemented in lib/CodeGen, so move the header there to match. This fixes a link error with modular codegeneration builds - where a header and its implementation are circularly dependent and so need to be in the same library, not split between two like this. llvm-svn: 317379
* Revert "TargetMachine: Merge TargetMachine and LLVMTargetMachine"Matthias Braun2017-10-121-3/+3
| | | | | | | | | | Reverting to investigate layering effects of MCJIT not linking libCodeGen but using TargetMachine::getNameWithPrefix() breaking the lldb bots. This reverts commit r315633. llvm-svn: 315637
* TargetMachine: Merge TargetMachine and LLVMTargetMachineMatthias Braun2017-10-121-3/+3
| | | | | | | | | | | | | | | Merge LLVMTargetMachine into TargetMachine. - There is no in-tree target anymore that just implements TargetMachine but not LLVMTargetMachine. - It should still be possible to stub out all the various functions in case a target does not want to use lib/CodeGen - This simplifies the code and avoids methods ending up in the wrong interface. Differential Revision: https://reviews.llvm.org/D38489 llvm-svn: 315633
* MachineInstr: Make isEqual agree with getHashValue in ↵Diana Picus2017-10-122-0/+250
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MachineInstrExpressionTrait MachineInstr::isIdenticalTo has a lot of logic for dealing with register Defs (i.e. deciding whether to take them into account or ignore them). This logic gets things wrong in some obscure cases, for instance if an operand is not a Def for both the current MI and the one we are comparing to. I'm not sure if it's possible for this to happen for regular register operands, but it may happen in the ARM backend for special operands which use sentinel values for the register (i.e. 0, which is neither a physical register nor a virtual one). This causes MachineInstrExpressionTrait::isEqual (which uses MachineInstr::isIdenticalTo) to return true for the following instructions, which are the same except for the fact that one sets the flags and the other one doesn't: %1114 = ADDrsi %1113, %216, 17, 14, _, def _ %1115 = ADDrsi %1113, %216, 17, 14, _, _ OTOH, MachineInstrExpressionTrait::getHashValue returns different values for the 2 instructions due to the different isDef on the last operand. In practice this means that when trying to add those instructions to a DenseMap, they will be considered different because of their different hash values, but when growing the map we might get an assertion while copying from the old buckets to the new buckets because isEqual misleadingly returns true. This patch makes sure that isEqual and getHashValue agree, by improving the checks in MachineInstr::isIdenticalTo when we are ignoring virtual register definitions (which is what the Trait uses). Firstly, instead of checking isPhysicalRegister, we use !isVirtualRegister, so that we cover both physical registers and sentinel values. Secondly, instead of checking MachineOperand::isReg, we use MachineOperand::isIdenticalTo, which checks isReg, isSubReg and isDef, which are the same values that the hash function uses to compute the hash. Note that the function is symmetric with this change, since if the current operand is not a Def, we check MachineOperand::isIdenticalTo, which returns false if the operands have different isDef's. Differential Revision: https://reviews.llvm.org/D38789 llvm-svn: 315579
* [unittests] Adding a unittest for ChangeTaTargetIndex. NFCMarcello Maggioni2017-08-102-0/+41
| | | | | | Differential Revision: https://reviews.llvm.org/D36565 llvm-svn: 310610
* [GlobalISel] Make GlobalISel a non-optional library.Quentin Colombet2017-08-031-5/+3
| | | | | | | | With this change, the GlobalISel library gets always built. In particular, this is not possible to opt GlobalISel out of the build using the LLVM_BUILD_GLOBAL_ISEL variable any more. llvm-svn: 309990
* [GlobalISel] Make multi-step legalization work.Kristof Beyls2017-06-301-0/+19
| | | | | | | | | | | | | | | | In r301116, a custom lowering needed to be introduced to be able to legalize 8 and 16-bit divisions on ARM targets without a division instruction, since 2-step legalization (WidenScalar from 8 bit to 32 bit, then Libcall the 32-bit division) doesn't work. This fixes this and makes this kind of multi-step legalization, where first the size of the type needs to be changed and then some action is needed that doesn't require changing the size of the type, straighforward to specify. Differential Revision: https://reviews.llvm.org/D32529 llvm-svn: 306806
* Added braces to work around gcc warning in googletest: suggest explicit ↵Galina Kistanova2017-06-151-1/+2
| | | | | | braces to avoid ambiguous 'else'. NFC. llvm-svn: 305506
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-071-1/+1
| | | | | | | | | | | | This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
* Re-sort #include lines for unittests. This uses a slightly modifiedChandler Carruth2017-06-062-2/+2
| | | | | | | | | | | | | | | clang-format (https://reviews.llvm.org/D33932) to keep primary headers at the top and handle new utility headers like 'gmock' consistently with other utility headers. No other change was made. I did no manual edits, all of this is clang-format. This should allow other changes to have more clear and focused diffs, and is especially motivated by moving some headers into more focused libraries. llvm-svn: 304786
* [SVE] Fix mismatched sign comparison warning in unit test from r300842.Amara Emerson2017-04-201-2/+2
| | | | llvm-svn: 300855
* [MVT][SVE] Scalable vector MVTs (3/3)Amara Emerson2017-04-202-0/+89
| | | | | | | | | | | | Adds MVT::ElementCount to represent the length of a vector which may be scalable, then adds helper functions that work with it. Patch by Graham Hunter. Differential Revision: https://reviews.llvm.org/D32019 llvm-svn: 300842
* [GlobalISel] Support vector-of-pointers in LLTKristof Beyls2017-04-191-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes PR32471. As comment 10 on that bug report highlights (https://bugs.llvm.org//show_bug.cgi?id=32471#c10), there are quite a few different defendable design tradeoffs that could be made, including not representing pointers at all in LLT. I decided to go for representing vector-of-pointer as a concept in LLT, while keeping the size of the LLT type 64 bits (this is an increase from 48 bits before). My rationale for keeping pointers explicit is that on some targets probably it's very handy to have the distinction between pointer and non-pointer (e.g. 68K has a different register bank for pointers IIRC). If we keep a scalar pointer, it probably is easiest to also have a vector-of-pointers to keep LLT relatively conceptually clean and orthogonal, while we don't have a very strong reason to break that orthogonality. Once we gain more experience on the use of LLT, we can of course reconsider this direction. Rejecting vector-of-pointer types in the IRTranslator is also an option to avoid the crash reported in PR32471, but that is only a very short-term solution; also needs quite a bit of code tweaks in places, and is probably fragile. Therefore I didn't consider this the best option. llvm-svn: 300664
* Revert "[GlobalISel] Support vector-of-pointers in LLT"Kristof Beyls2017-04-181-11/+0
| | | | | | | | | | | | | | | | This reverts r300535 and r300537. The newly added tests in test/CodeGen/AArch64/GlobalISel/arm64-fallback.ll produces slightly different code between LLVM versions being built with different compilers. E.g., dependent on the compiler LLVM is built with, either one of the following can be produced: remark: <unknown>:0:0: unable to legalize instruction: %vreg0<def>(p0) = G_EXTRACT_VECTOR_ELT %vreg1, %vreg2; (in function: vector_of_pointers_extractelement) remark: <unknown>:0:0: unable to legalize instruction: %vreg2<def>(p0) = G_EXTRACT_VECTOR_ELT %vreg1, %vreg0; (in function: vector_of_pointers_extractelement) Non-determinism like this is clearly a bad thing, so reverting this until I can find and fix the root cause of the non-determinism. llvm-svn: 300538
* [GlobalISel] Support vector-of-pointers in LLTKristof Beyls2017-04-181-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes PR32471. As comment 10 on that bug report highlights (https://bugs.llvm.org//show_bug.cgi?id=32471#c10), there are quite a few different defendable design tradeoffs that could be made, including not representing pointers at all in LLT. I decided to go for representing vector-of-pointer as a concept in LLT, while keeping the size of the LLT type 64 bits (this is an increase from 48 bits before). My rationale for keeping pointers explicit is that on some targets probably it's very handy to have the distinction between pointer and non-pointer (e.g. 68K has a different register bank for pointers IIRC). If we keep a scalar pointer, it probably is easiest to also have a vector-of-pointers to keep LLT relatively conceptually clean and orthogonal, while we don't have a very strong reason to break that orthogonality. Once we gain more experience on the use of LLT, we can of course reconsider this direction. Rejecting vector-of-pointer types in the IRTranslator is also an option to avoid the crash reported in PR32471, but that is only a very short-term solution; also needs quite a bit of code tweaks in places, and is probably fragile. Therefore I didn't consider this the best option. llvm-svn: 300535
* Recommit: [globalisel] Change LLT constructor string into an LLT-based ↵Daniel Sanders2017-03-071-3/+3
| | | | | | | | | | | | | | | | | | | | object that knows how to generate it. Summary: This will allow future patches to inspect the details of the LLT. The implementation is now split between the Support and CodeGen libraries to allow TableGen to use this class without introducing layering concerns. Thanks to Ahmed Bougacha for finding a reasonable way to avoid the layering issue and providing the version of this patch without that problem. The problem with the previous commit appears to have been that TableGen was including CodeGen/LowLevelType.h instead of Support/LowLevelTypeImpl.h. Reviewers: t.p.northover, qcolombet, rovka, aditya_nandakumar, ab, javed.absar Subscribers: arsenm, nhaehnle, mgorny, dberris, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D30046 llvm-svn: 297241
* Revert r297177: Change LLT constructor string into an LLT-based object ...Daniel Sanders2017-03-071-3/+3
| | | | | | | | | | More module problems. This time it only showed up in the stage 2 compile of clang-x86_64-linux-selfhost-modules-2 but not the stage 1 compile. Somehow, this change causes the build to need Attributes.gen before it's been generated. llvm-svn: 297188
* [globalisel] Change LLT constructor string into an LLT-based object that ↵Daniel Sanders2017-03-071-3/+3
| | | | | | | | | | | | | | | | | | knows how to generate it. Summary: This will allow future patches to inspect the details of the LLT. The implementation is now split between the Support and CodeGen libraries to allow TableGen to use this class without introducing layering concerns. Thanks to Ahmed Bougacha for finding a reasonable way to avoid the layering issue and providing the version of this patch without that problem. Reviewers: t.p.northover, qcolombet, rovka, aditya_nandakumar, ab, javed.absar Subscribers: arsenm, nhaehnle, mgorny, dberris, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D30046 llvm-svn: 297177
* Revert r296474 - [globalisel] Change LLT constructor string into an LLT ↵Daniel Sanders2017-02-281-3/+3
| | | | | | | | subclass that knows how to generate it. There's a circular dependency that's only revealed when LLVM_ENABLE_MODULES=1. llvm-svn: 296478
* [globalisel] Change LLT constructor string into an LLT subclass that knows ↵Daniel Sanders2017-02-281-3/+3
| | | | | | | | | | | | | | | | | | how to generate it. Summary: This will allow future patches to inspect the details of the LLT. The implementation is now split between the Support and CodeGen libraries to allow TableGen to use this class without introducing layering concerns. Thanks to Ahmed Bougacha for finding a reasonable way to avoid the layering issue and providing the version of this patch without that problem. Reviewers: t.p.northover, qcolombet, rovka, aditya_nandakumar, ab, javed.absar Subscribers: arsenm, nhaehnle, mgorny, dberris, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D30046 llvm-svn: 296474
* ADT: Add explicit conversions for reverse ilist iteratorsDuncan P. N. Exon Smith2017-02-071-0/+64
| | | | | | | | | | | | | | | Add explicit conversions between forward and reverse ilist iterators. These follow the conversion conventions of std::reverse_iterator, which are off-by-one: the newly-constructed "reverse" iterator dereferences to the previous node of the one sent in. This has the benefit of converting reverse ranges in place: - If [I, E) is a valid range, - then [reverse(E), reverse(I)) gives the same range in reverse order. ilist_iterator::getReverse() is unchanged: it returns a reverse iterator to the *same* node. llvm-svn: 294349
* GlobalISel: rename legalizer components to match others.Tim Northover2016-10-143-121/+121
| | | | | | | | | | The previous names were both misleading (the MachineLegalizer actually contained the info tables) and inconsistent with the selector & translator (in having a "Machine") prefix. This should make everything sensible again. The only functional change is the name of a couple of command-line options. llvm-svn: 284287
* [GlobalISel] Get the AArch64 tests to work on LinuxDiana Picus2016-10-141-0/+1
| | | | | | | | | | Mostly this just means changing the triple from aarch64-apple-ios to the generic aarch64--. Only one test needs more significant changes, but GlobalISel already does the right thing so it's ok to just change the checks. Differential Revision: https://reviews.llvm.org/D25532 llvm-svn: 284223
* GlobalISel: fix misuse of using declaration in test.Tim Northover2016-10-061-48/+41
| | | | | | Clang didn't diagnose it before. Oops. llvm-svn: 283451
* GlobalISel: remove "unsized" LLTTim Northover2016-09-151-20/+0
| | | | | | | | 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: cache pointer sizes in LLTTim Northover2016-09-152-13/+19
| | | | | | | Otherwise everything that needs to work out what size they are has to keep a DataLayout handy, which is a bit silly and very annoying. llvm-svn: 281597
* CodeGen: Give MachineBasicBlock::reverse_iterator a handle to the current MIDuncan P. N. Exon Smith2016-09-111-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that MachineBasicBlock::reverse_instr_iterator knows when it's at the end (since r281168 and r281170), implement MachineBasicBlock::reverse_iterator directly on top of an ilist::reverse_iterator by adding an IsReverse template parameter to MachineInstrBundleIterator. This replaces another hard-to-reason-about use of std::reverse_iterator on list iterators, matching the changes for ilist::reverse_iterator from r280032 (see the "out of scope" section at the end of that commit message). MachineBasicBlock::reverse_iterator now has a handle to the current node and has obvious invalidation semantics. r280032 has a more detailed explanation of how list-style reverse iterators (invalidated when the pointed-at node is deleted) are different from vector-style reverse iterators like std::reverse_iterator (invalidated on every operation). A great motivating example is this commit's changes to lib/CodeGen/DeadMachineInstructionElim.cpp. Note: If your out-of-tree backend deletes instructions while iterating on a MachineBasicBlock::reverse_iterator or converts between MachineBasicBlock::iterator and MachineBasicBlock::reverse_iterator, you'll need to update your code in similar ways to r280032. The following table might help: [Old] ==> [New] delete &*RI, RE = end() delete &*RI++ RI->erase(), RE = end() RI++->erase() reverse_iterator(I) std::prev(I).getReverse() reverse_iterator(I) ++I.getReverse() --reverse_iterator(I) I.getReverse() reverse_iterator(std::next(I)) I.getReverse() RI.base() std::prev(RI).getReverse() RI.base() ++RI.getReverse() --RI.base() RI.getReverse() std::next(RI).base() RI.getReverse() (For more details, have a look at r280032.) llvm-svn: 281172
* CodeGen: Assert that bundle iterators are validDuncan P. N. Exon Smith2016-09-111-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | Add an assertion to the MachineInstrBundleIterator from instr_iterator that the underlying iterator is valid. This is possible know that we can check ilist_node::isSentinel (since r281168), and is consistent with the constructors from MachineInstr* and MachineInstr&. Avoiding the new assertion in operator== and operator!= requires four (!!!!) new overloads each. (As an aside, I'm strongly in favour of: - making the conversion from instr_iterator explicit; - making the conversion from pointer explicit; - making the conversion from reference explicit; and - removing all the extra overloads of operator== and operator!= except const_instr_iterator. I'm not signing up for that at this point, but being clear about when something is an MachineInstr-iterator (possibly instr_end()) vs MachineInstr-bundle-iterator (possibly end()) vs MachineInstr* (possibly nullptr) vs MachineInstr& (known valid) would surely make code cleaner... and it would remove a ton of boilerplate from MachineInstrBundleIterator operators.) llvm-svn: 281170
* CodeGen: Turn on sentinel tracking for MachineInstr iteratorsDuncan P. N. Exon Smith2016-09-111-1/+2
| | | | | | | | | | | | | | | | | | | | This is a prep commit before fixing MachineBasicBlock::reverse_iterator invalidation semantics, ala r281167 for ilist::reverse_iterator. This changes MachineBasicBlock::Instructions to track which node is the sentinel regardless of LLVM_ENABLE_ABI_BREAKING_CHECKS. There's almost no functionality change (aside from ABI). However, in the rare configuration: #if !defined(NDEBUG) && !defined(LLVM_ENABLE_ABI_BREAKING_CHECKS) the isKnownSentinel() assertions in ilist_iterator<>::operator* suddenly have teeth for MachineInstr. If these assertions start firing for your out-of-tree backend, have a look at the suggestions in the commit message for r279314, and at some of the commits leading up to it that avoid dereferencing the end() iterator. llvm-svn: 281168
* GlobalISel: use multi-dimensional arrays for legalize actions.Tim Northover2016-08-291-0/+2
| | | | | | | | | | | Instead of putting all possible requests into a single table, we can perform the extremely dense lookup based on opcode and type-index in constant time using multi-dimensional array-like things. This roughly halves the time spent doing legalization, which was dominated by queries against the Actions table. llvm-svn: 280011
* GlobalISel: legalize sdiv and srem operations.Tim Northover2016-08-261-0/+2
| | | | llvm-svn: 279842
* GlobalISel: extend legalizer interface to handle multiple types.Tim Northover2016-08-231-22/+42
| | | | | | | | Instructions like G_ICMP have multiple types that may need to be legalized (the boolean output and nearly arbitrary inputs in this case). So the legalizer must be capable of deciding what to do for each of them separately. llvm-svn: 279554
* GlobalISel: support loads and stores of strange types.Tim Northover2016-08-151-4/+4
| | | | | | | Before we mischaracterized structs and i1 types as a scalar with size 0 in various ways. llvm-svn: 278744
* ADT: Remove all ilist_iterator => pointer casts, NFCDuncan P. N. Exon Smith2016-08-122-0/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove all ilist_iterator to pointer casts. There were two reasons for casts: - Checking for an uninitialized (i.e., null) iterator. I added MachineInstrBundleIterator::isValid() to check for that case. - Comparing an iterator against the underlying pointer value while avoiding converting the pointer value to an iterator. This is occasionally necessary in MachineInstrBundleIterator, since there is an assertion in the constructors that the underlying MachineInstr is not bundled (but we don't care about that if we're just checking for pointer equality). To support the latter case, I rewrote the == and != operators for ilist_iterator and MachineInstrBundleIterator. - The implicit constructors now use enable_if to exclude const-iterator => non-const-iterator conversions from overload resolution (previously it was a compiler error on instantiation, now it's SFINAE). - The == and != operators are now global (friends), and are not templated. - MachineInstrBundleIterator has overloads to compare against both const_pointer and const_reference. This avoids the implicit conversions to MachineInstrBundleIterator that assert, instead just checking the address (and I added unit tests to confirm this). Notably, the only remaining uses of ilist_iterator::getNodePtrUnchecked are in ilist.h, and no code outside of ilist*.h directly relies on this UB end-iterator-to-pointer conversion anymore. It's still needed for ilist_*sentinel_traits, but I'll clean that up soon. llvm-svn: 278478
* GlobalISel: refuse to halve size of 1-byte & odd-sized LLTs.Tim Northover2016-08-041-9/+12
| | | | llvm-svn: 277768
* [GlobalISel] Add missing link components to r277160 unittest. NFC.Ahmed Bougacha2016-07-291-0/+2
| | | | | | | It broke a shared builder: http://lab.llvm.org:8011/builders/llvm-mips-linux/builds/17320 llvm-svn: 277201
* [GlobalISel] Add LLT::operator!=().Ahmed Bougacha2016-07-291-0/+13
| | | | llvm-svn: 277162
* [GlobalISel] Fix LLT::unsized to match LLT(LabelTy).Ahmed Bougacha2016-07-291-0/+5
| | | | | | | | | When coming from an IR label type, we set a 0 NumElements, but not when constructing an LLT using unsized(), causing comparisons to fail. Pick one variant and fix the other. llvm-svn: 277161
* [GlobalISel] Add unittests for LowLevelType.Ahmed Bougacha2016-07-292-0/+199
| | | | llvm-svn: 277160
* GlobalISel: implement Legalization querying framework.Tim Northover2016-07-203-0/+113
| | | | | | | This adds an (incomplete, inefficient) framework for deciding what to do with some operation on a given type. llvm-svn: 276184
* Fix header comment in unittests/CodeGen/DIEHashTest.cpp.Justin Lebar2016-07-131-1/+1
| | | | llvm-svn: 275296
* Remove autoconf supportChris Bieneman2016-01-261-16/+0
| | | | | | | | | | | | | | | | Summary: This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html "I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened." - Obi Wan Kenobi Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D16471 llvm-svn: 258861
* AsmPrinter: Use an intrusively linked list for DIE::ChildrenDuncan P. N. Exon Smith2015-06-251-64/+63
| | | | | | | | | | | | | | Replace the `std::vector<>` for `DIE::Children` with an intrusively linked list. This is a strict memory improvement: it requires no auxiliary storage, and reduces `sizeof(DIE)` by one pointer. It also factors out the DIE-related malloc traffic. This drops llc memory usage from 735 MB down to 718 MB, or ~2.3%. (I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`; see r236629 for details.) llvm-svn: 240736
* AsmPrinter: Convert DIE::Values to a linked listDuncan P. N. Exon Smith2015-06-251-161/+193
| | | | | | | | | | | | | | | | Change `DIE::Values` to a singly linked list, where each node is allocated on a `BumpPtrAllocator`. In order to support `push_back()`, the list is circular, and points at the tail element instead of the head. I abstracted the core list logic out to `IntrusiveBackList` so that it can be reused for `DIE::Children`, which also cares about `push_back()`. This drops llc memory usage from 799 MB down to 735 MB, about 8%. (I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`; see r236629 for details.) llvm-svn: 240733
OpenPOWER on IntegriCloud