summaryrefslogtreecommitdiffstats
path: root/llvm/utils
Commit message (Collapse)AuthorAgeFilesLines
* [DFAPacketizer] Reapply: Track resources for packetized instructionsJames Molloy2019-09-091-48/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reapply with fix to reduce resources required by the compiler - use unsigned[2] instead of std::pair. This causes clang and gcc to compile the generated file multiple times faster, and hopefully will reduce the resource requirements on Visual Studio also. This fix is a little ugly but it's clearly the same issue the previous author of DFAPacketizer faced (the previous tables use unsigned[2] rather uglily too). This patch allows the DFAPacketizer to be queried after a packet is formed to work out which resources were allocated to the packetized instructions. This is particularly important for targets that do their own bundle packing - it's not sufficient to know simply that instructions can share a packet; which slots are used is also required for encoding. This extends the emitter to emit a side-table containing resource usage diffs for each state transition. The packetizer maintains a set of all possible resource states in its current state. After packetization is complete, all remaining resource states are possible packetization strategies. The sidetable is only ~500K for Hexagon, but the extra tracking is disabled by default (most uses of the packetizer like MachinePipeliner don't care and don't need the extra maintained state). Differential Revision: https://reviews.llvm.org/D66936 llvm-svn: 371399
* Revert rL371198 from llvm/trunk: [DFAPacketizer] Track resources for ↵Simon Pilgrim2019-09-091-92/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | packetized instructions This patch allows the DFAPacketizer to be queried after a packet is formed to work out which resources were allocated to the packetized instructions. This is particularly important for targets that do their own bundle packing - it's not sufficient to know simply that instructions can share a packet; which slots are used is also required for encoding. This extends the emitter to emit a side-table containing resource usage diffs for each state transition. The packetizer maintains a set of all possible resource states in its current state. After packetization is complete, all remaining resource states are possible packetization strategies. The sidetable is only ~500K for Hexagon, but the extra tracking is disabled by default (most uses of the packetizer like MachinePipeliner don't care and don't need the extra maintained state). Differential Revision: https://reviews.llvm.org/D66936 ........ Reverted as this is causing "compiler out of heap space" errors on MSVC 2017/19 NDEBUG builds llvm-svn: 371393
* [git-llvm] Do not reinvent `@{upstream}`David Zarzycki2019-09-071-12/+2
| | | | | | | | Make `git-llvm` more robust when used with a nontrivial repository. https://reviews.llvm.org/D67262 llvm-svn: 371290
* GlobalISel: Support physical register inputs in patternsMatt Arsenault2019-09-063-11/+177
| | | | llvm-svn: 371253
* [DFAPacketizer] Track resources for packetized instructionsJames Molloy2019-09-061-48/+92
| | | | | | | | | | | | | | | | | | | | | | This patch allows the DFAPacketizer to be queried after a packet is formed to work out which resources were allocated to the packetized instructions. This is particularly important for targets that do their own bundle packing - it's not sufficient to know simply that instructions can share a packet; which slots are used is also required for encoding. This extends the emitter to emit a side-table containing resource usage diffs for each state transition. The packetizer maintains a set of all possible resource states in its current state. After packetization is complete, all remaining resource states are possible packetization strategies. The sidetable is only ~500K for Hexagon, but the extra tracking is disabled by default (most uses of the packetizer like MachinePipeliner don't care and don't need the extra maintained state). Differential Revision: https://reviews.llvm.org/D66936 llvm-svn: 371198
* gn build: Merge r371182Nico Weber2019-09-061-0/+1
| | | | llvm-svn: 371191
* gn build: Merge r371179Nico Weber2019-09-061-0/+1
| | | | llvm-svn: 371190
* gn build: Merge r371159Nico Weber2019-09-061-0/+1
| | | | llvm-svn: 371161
* GlobalISel/TableGen: Fix handling of EXTRACT_SUBREG constraintsMatt Arsenault2019-09-061-19/+47
| | | | | | | | | | | | | | | | This was only using the correct register constraints if this was the final result instruction. If the extract was a sub instruction of the result, it would attempt to use GIR_ConstrainSelectedInstOperands on a COPY, which won't work. Move the handling to createAndImportSubInstructionRenderer so it works correctly. I don't fully understand why runOnPattern and createAndImportSubInstructionRenderer both need to handle these special cases, and constrain them with slightly different methods. If I remove the runOnPattern handling, it does break the constraint when the final result instruction is EXTRACT_SUBREG. llvm-svn: 371150
* gn build: Merge r371134Nico Weber2019-09-051-0/+1
| | | | llvm-svn: 371135
* gn build: Merge r371121Nico Weber2019-09-051-0/+1
| | | | llvm-svn: 371123
* gn build: Merge r371117Nico Weber2019-09-051-1/+0
| | | | llvm-svn: 371119
* gn build: Merge r371103Nico Weber2019-09-051-0/+1
| | | | llvm-svn: 371105
* gn build: (manually) merge r358706Nico Weber2019-09-051-18/+24
| | | | llvm-svn: 371102
* gn build: (manually) merge r371003Nico Weber2019-09-051-0/+3
| | | | llvm-svn: 371091
* gn build: Merge r370985Nico Weber2019-09-041-0/+1
| | | | llvm-svn: 370988
* GlobalISel/TableGen: Don't skip REG_SEQUENCE based on patternsMatt Arsenault2019-09-041-25/+31
| | | | | | | | This partially adds support for patterns with REG_SEQUENCE. The source patterns are now accepted, but the pattern is still rejected due to missing support for the instruction renderer. llvm-svn: 370920
* gn build: Merge r370862Nico Weber2019-09-042-2/+2
| | | | llvm-svn: 370876
* Revert "[Clang Interpreter] Initial patch for the constexpr interpreter"Roman Lebedev2019-09-043-41/+0
| | | | | | | | | Breaks BUILD_SHARED_LIBS build, introduces cycles in library dependency graphs. (clangInterp depends on clangAST which depends on clangInterp) This reverts r370839, which is an yet another recommit of D64146. llvm-svn: 370874
* gn build: Merge r370843Nico Weber2019-09-041-0/+1
| | | | llvm-svn: 370844
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-09-043-0/+41
| | | | | | | | | | | | | | | | | | Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 370839
* gn build: (manually) merge r370499Nico Weber2019-09-032-0/+12
| | | | llvm-svn: 370752
* gn build: Merge r370746Nico Weber2019-09-032-0/+2
| | | | llvm-svn: 370749
* Revert [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-09-023-41/+0
| | | | | | This reverts r370636 (git commit 8327fed9475a14c3376b4860c75370c730e08f33) llvm-svn: 370642
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-09-023-0/+41
| | | | | | | | | | | | | | | | | | Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 370636
* Revert [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-313-41/+0
| | | | | | This reverts r370584 (git commit afcb3de117265a69d21e5673356e925a454d7d02) llvm-svn: 370588
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-313-0/+41
| | | | | | | | | | | | | | | | | | Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 370584
* gn build: Merge r370512Nico Weber2019-08-301-0/+1
| | | | llvm-svn: 370516
* [DFAPacketizer] Allow namespacing of automata per-itineraryJames Molloy2019-08-301-24/+41
| | | | | | | | | | | | | | | | | | | | | The Hexagon itineraries are cunningly crafted such that functional units between itineraries do not clash. Because all itineraries are bundled into the same DFA, a functional unit index clash would cause an incorrect DFA to be generated. A workaround for this is to ensure all itineraries declare the universe of all possible functional units, but this isn't ideal for three reasons: 1) We only have a limited number of FUs we can encode in the packetizer, and using the universe causes us to hit the limit without care. 2) Silent codegen faults are bad, and careful triage of the FU list shouldn't be required. 3) Smooshing all itineraries into the same automaton allows combinations of instruction classes that cannot exist, which bloats the table. A simple solution is to allow "namespacing" packetizers. Differential Revision: https://reviews.llvm.org/D66940 llvm-svn: 370508
* gn build: Merge r370500Nico Weber2019-08-301-0/+1
| | | | llvm-svn: 370501
* [ValueTypes] Add v16f16 and v32f16 to EVT::getEVTString and Tablegen's ↵Craig Topper2019-08-301-0/+2
| | | | | | | | getEnumName Missed these when I hadded the enum entries llvm-svn: 370494
* gn build: Merge r370490Nico Weber2019-08-301-0/+1
| | | | llvm-svn: 370492
* vim: add `immarg` keywordSven van Haastregt2019-08-301-0/+1
| | | | | | The `immarg` attribute was added in r355981. llvm-svn: 370443
* gn build: Merge r370441Nico Weber2019-08-301-1/+0
| | | | llvm-svn: 370442
* GlobalISel/TableGen: Handle setcc patternsMatt Arsenault2019-08-291-1/+68
| | | | | | | | | | | This is a special case because one node maps to two different G_ instructions, and the operand order is changed. This mostly enables G_FCMP for AMDPGPU. G_ICMP is still manually selected for now since it has the SALU and VALU complication to deal with. llvm-svn: 370280
* Add tie-breaker for register class sorting in getSuperRegForSubRegJessica Paquette2019-08-281-1/+8
| | | | | | | | | | | | llvm::stable_sort is apparently not sufficient. Use the same tie-breaker/sorting style as TopoOrderRC fix bot failures. E.g. http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/19401/steps/test-check-all/logs/stdio llvm-svn: 370267
* [GlobalISel] Import patterns containing SUBREG_TO_REGJessica Paquette2019-08-281-19/+85
| | | | | | | | | | | | | | | | | | | | | | | Reuse the logic for INSERT_SUBREG to also import SUBREG_TO_REG patterns. - Split `inferSuperRegisterClass` into two functions, one which tries to use an existing TreePatternNode (`inferSuperRegisterClassForNode`), and one that doesn't. SUBREG_TO_REG doesn't have a node to leverage, which is the cause for the split. - Rename GlobalISelEmitterInsertSubreg.td to GlobalISelEmitterSubreg.td and update it. - Update impacted tests in the AArch64 and X86 backends. This is kind of a hit/miss for code size improvements/regressions. E.g. in add-ext.ll, we now get some identity copies. This isn't really anything the importer can handle, since it's caused by a later pass introducing the copy for the sake of correctness. Differential Revision: https://reviews.llvm.org/D66769 llvm-svn: 370254
* gn build: Merge r370249Nico Weber2019-08-281-0/+1
| | | | llvm-svn: 370251
* gn build: Merge r370187Nico Weber2019-08-281-0/+1
| | | | llvm-svn: 370188
* Recommit "[GlobalISel] Import patterns containing INSERT_SUBREG"Jessica Paquette2019-08-273-1/+235
| | | | | | | | | | I thought `llvm::sort` was stable for some reason but it's not. Use `llvm::stable_sort` in `CodeGenTarget::getSuperRegForSubReg`. Original patch: https://reviews.llvm.org/D66498 llvm-svn: 370084
* Revert "[GlobalISel] Import patterns containing INSERT_SUBREG"Jessica Paquette2019-08-273-235/+1
| | | | | | | | | | When EXPENSIVE_CHECKS are enabled, GlobalISelEmitterSubreg.td doesn't get stable output. Reverting while I debug it. See: https://reviews.llvm.org/D66498 llvm-svn: 370080
* [IntrinsicEmitter] Support scalable vectors in intrinsicsCullen Rhodes2019-08-271-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds support for scalable vectors in intrinsics, enabling intrinsics such as the following to be defined: declare <vscale x 4 x i32> @llvm.something.nxv4i32(<vscale x 4 x i32>) Support for this is implemented by defining a new type descriptor for scalable vectors and adding mangling support for scalable vector types in the name mangling scheme used by 'any' types in intrinsic signatures. Tests have been added for IRBuilder to test scalable vectors work as expected when using intrinsics through this interface. This required implementing an intrinsic that is explicitly defined with scalable vectors, e.g. LLVMType<nxv4i32>, an SVE floating-point convert intrinsic was used for this. The behaviour of the overloaded type LLVMScalarOrSameVectorWidth with scalable vectors is tested using the existing masked load intrinsic. Also added an .ll test to test the Verifier catches a bad intrinsic argument when passing a fixed-width predicate (mask) to the masked.load intrinsic where a scalable is expected. Patch by Paul Walker Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D65930 llvm-svn: 370053
* [GlobalISel] Import patterns containing INSERT_SUBREGJessica Paquette2019-08-263-1/+235
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This teaches the importer to handle INSERT_SUBREG instructions. We were missing patterns involving INSERT_SUBREG in AArch64. It appears in AArch64InstrInfo.td 107 times, and 14 times in AArch64InstrFormats.td. To meaningfully import it, the GlobalISelEmitter needs to know how to infer a super register class for a given register class. This patch introduces the following: - `getSuperRegForSubReg`, a function which finds the largest register class which supports a value type and subregister index - `inferSuperRegisterClass`, a function which finds the appropriate super register class for an INSERT_SUBREG' - `inferRegClassFromPattern`, a function which allows for some trivial lookthrough into instructions - `getRegClassFromLeaf`, a helper function which returns the register class for a leaf `TreePatternNode` - Support for subregister index operands in `importExplicitUseRenderer` It also - Updates tests in each backend which are impacted by the change - Adds GlobalISelEmitterSubreg.td to test that we import and skip the expected patterns As a result of this patch, INSERT_SUBREG patterns in X86 may use the LOW32_ADDR_ACCESS_RBP register class instead of GR32. This is correct, since the register class contains the same registers as GR32 (except with the addition of RBP). So, this also teaches X86 to handle that register class. This is in line with X86ISelLowering, which treats this as a GR class. Differential Revision: https://reviews.llvm.org/D66498 llvm-svn: 369973
* gn build: Merge r369918Nico Weber2019-08-262-0/+2
| | | | llvm-svn: 369953
* gn build: color linker errors when using lldNico Weber2019-08-261-0/+3
| | | | llvm-svn: 369951
* gn build: (manually) merge r369741Nico Weber2019-08-261-0/+2
| | | | llvm-svn: 369950
* gn build: (manually) merge r369940Nico Weber2019-08-262-0/+8
| | | | llvm-svn: 369948
* [TableGen] Correct comments for end of namespace. NFCBjorn Pettersson2019-08-2510-29/+29
| | | | | | | | | | | | | | | | | | | | | | Summary: Update end-of-namespace comments generated by tablegen emitters to fulfill the rules setup by clang-tidy's llvm-namespace-comment checker. Fixed a few end-of-namespace comments in the tablegen source code as well. Reviewers: craig.topper Reviewed By: craig.topper Subscribers: craig.topper, stoklund, dschuff, sbc100, jgravelle-google, aheejin, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66396 llvm-svn: 369865
* Use a bit of relaxed constexpr to make FeatureBitset costant intializableBenjamin Kramer2019-08-244-6/+6
| | | | | | | | | | | This requires std::intializer_list to be a literal type, which it is starting with C++14. The downside is that std::bitset is still not constexpr-friendly so this change contains a re-implementation of most of it. Shrinks clang by ~60k. llvm-svn: 369847
* hwasan: Untag unwound stack frames by wrapping personality functions.Peter Collingbourne2019-08-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | One problem with untagging memory in landing pads is that it only works correctly if the function that catches the exception is instrumented. If the function is uninstrumented, we have no opportunity to untag the memory. To address this, replace landing pad instrumentation with personality function wrapping. Each function with an instrumented stack has its personality function replaced with a wrapper provided by the runtime. Functions that did not have a personality function to begin with also get wrappers if they may be unwound past. As the unwinder calls personality functions during stack unwinding, the original personality function is called and the function's stack frame is untagged by the wrapper if the personality function instructs the unwinder to keep unwinding. If unwinding stops at a landing pad, the function is still responsible for untagging its stack frame if it resumes unwinding. The old landing pad mechanism is preserved for compatibility with old runtimes. Differential Revision: https://reviews.llvm.org/D66377 llvm-svn: 369721
OpenPOWER on IntegriCloud