summaryrefslogtreecommitdiffstats
path: root/llvm/docs
Commit message (Collapse)AuthorAgeFilesLines
...
* [SourceMgr][FileCheck] Obey -color by extending WithColorJoel E. Denny2018-10-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | (Relands r344930, reverted in r344935, and now hopefully fixed for Windows.) While this change specifically targets FileCheck, it affects any tool using the same SourceMgr facilities. Previously, -color was documented in FileCheck's -help output, but -color had no effect. Now, -color obeys its documentation: it forces colors to be used in FileCheck diagnostics even when stderr is not a terminal. -color is especially helpful when combined with FileCheck's -v, which can produce a long series of diagnostics that you might wish to pipe to a pager, such as less -R. The WithColor extensions here will also help to clean up color usage in FileCheck's annotated dump of input, which is proposed in D52999. Reviewed By: JDevlieghere, zturner Differential Revision: https://reviews.llvm.org/D53419 llvm-svn: 345202
* [docs] Add rawspeed to test-suite proposals.Michael Kruse2018-10-241-0/+7
| | | | | | | rawspeed was suggested by Simon Pilgrim and Roman Lebedev in llvm.org/PR34216 and reviews.llvm.org/D46714. llvm-svn: 345166
* [AMDGPU] Defined gfx909 Raven Ridge 2Tim Renouf2018-10-241-0/+6
| | | | | | | Differential Revision: https://reviews.llvm.org/D53418 Change-Id: Ie3d054f2e956c2768988c0f4c0ffd29a47294eef llvm-svn: 345120
* [test-suite/doc] Add list of programs we might add.Michael Kruse2018-10-232-0/+314
| | | | | | | | | | | | | | | | | | | | | | Add a list of benchmarks, applications and algorithms which are under discussion to be added to the test-suite. The initial list includes the the benchmarks mentioned at https://llvm.org/PR34216, missing SPEC benchmarks, some image processing algorithms and a few others. The bug tracker only allows adding to the discussion, not removing, commenting, adding details to individual benchmarks. The first proposal was to add these benchmark into the test-suite repository, but after a discussion, adding it to llvm/docs/Proposals seem more appropriate. One advantage is that llvm.org will have a browsable web page with these suggestions. Suggested-by: Hal Finkel Differential Revision: https://reviews.llvm.org/D46714 llvm-svn: 345074
* Revert r344930 as it broke some of the bots on Windows.Aaron Ballman2018-10-221-4/+0
| | | | | | http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/739 llvm-svn: 344935
* [SourceMgr][FileCheck] Obey -color by extending WithColorJoel E. Denny2018-10-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | While this change specifically targets FileCheck, it affects any tool using the same SourceMgr facilities. Previously, -color was documented in FileCheck's -help output, but -color had no effect. Now, -color obeys its documentation: it forces colors to be used in FileCheck diagnostics even when stderr is not a terminal. -color is especially helpful when combined with FileCheck's -v, which can produce a long series of diagnostics that you might wish to pipe to a pager, such as less -R. The WithColor extensions here will also help to clean up color usage in FileCheck's annotated dump of input, which is proposed in D52999. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D53419 llvm-svn: 344930
* [TI removal] Remove discussion of `TerminatorInst` from the LLVMChandler Carruth2018-10-182-13/+6
| | | | | | documentation. llvm-svn: 344727
* [X86] Support for the mno-tls-direct-seg-refs flagKristina Brooks2018-10-181-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Allows to disable direct TLS segment access (%fs or %gs). GCC supports a similar flag, it can be useful in some circumstances, e.g. when a thread context block needs to be updated directly from user space. More info and specific use cases: https://bugs.llvm.org/show_bug.cgi?id=16145 There is another revision for clang as well. Related: D53102 All X86 CodeGen tests appear to pass: ``` [46/47] Running lit suite /SourceCache/llvm-trunk-8.0/test/CodeGen Testing Time: 23.17s Expected Passes : 3801 Expected Failures : 15 Unsupported Tests : 8021 ``` Reviewed by: Craig Topper. Patch by nruslan (Ruslan Nikolaev). Differential Revision: https://reviews.llvm.org/D53103 llvm-svn: 344723
* [BuildingAJIT] Update the Ch1 KaleidoscopeJIT class to expose errors to clients.Lang Hames2018-10-181-80/+84
| | | | | | | | Returning the error to clients provides an opportunity to introduce readers to the Expected and Error APIs and makes the tutorial more useful as a starting point for a real JIT class, while only slightly complicating the code. llvm-svn: 344720
* [BuildingAJIT] Simplify a tutorial example and fix a syntax error.Lang Hames2018-10-171-3/+2
| | | | llvm-svn: 344712
* [BuildingAJIT] Fix a function signature in the documentation.Lang Hames2018-10-171-2/+2
| | | | llvm-svn: 344705
* [llvm-exegesis] Allow measuring several instructions in a single run.Clement Courbet2018-10-171-2/+3
| | | | | | | | | | | | | | | | Summary: We try to recover gracefully on instructions that would crash the program. This includes some refactoring of runMeasurement() implementations. Reviewers: gchatelet Subscribers: tschuett, llvm-commits Differential Revision: https://reviews.llvm.org/D53371 llvm-svn: 344695
* Document the behavior of option passing when using -DCLANG_ENABLE_BOOTSTRAP=OnSylvestre Ledru2018-10-171-0/+10
| | | | | | | | | | | | Also document -DCLANG_BOOTSTRAP_PASSTHROUGH Reviewers: ecbeckmann Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D53018 llvm-svn: 344669
* [BuildingAJIT] Update chapter 1 to use the ORCv2 APIs.Lang Hames2018-10-171-239/+156
| | | | llvm-svn: 344667
* fix an out of date paragraph noticed by Bryce LelbachChris Lattner2018-10-161-4/+0
| | | | llvm-svn: 344621
* [Intrinsic] Add llvm.minimum and llvm.maximum instrinsic functionsThomas Lively2018-10-131-0/+76
| | | | | | | | | | | | | | | | | | | | | | | | Summary: These new intrinsics have the semantics of the `minimum` and `maximum` operations specified by the latest draft of IEEE 754-2018. Unlike llvm.minnum and llvm.maxnum, these new intrinsics propagate NaNs and always treat -0.0 as less than 0.0. `minimum` and `maximum` lower directly to the existing `fminnan` and `fmaxnan` ISel DAG nodes. It is safe to reuse these DAG nodes because before this patch were only emitted in situations where there were known to be no NaN arguments or where NaN propagation was correct and there were known to be no zero arguments. I know of only four backends that lower fminnan and fmaxnan: WebAssembly, ARM, AArch64, and SystemZ, and each of these lowers fminnan and fmaxnan to instructions that are compatible with the IEEE 754-2018 semantics. Reviewers: aheejin, dschuff, sunfish, javed.absar Subscribers: kristof.beyls, dexonsmith, kristina, llvm-commits Differential Revision: https://reviews.llvm.org/D52764 llvm-svn: 344437
* [doc] Update the programmer's manual about SmallSet's iteratorKristof Umann2018-10-041-8/+6
| | | | | | | | Since rL337818, you can now iterate the SmallSet. Differential Revision: https://reviews.llvm.org/D52828 llvm-svn: 343770
* The llvm-exegesis output file is a html file not a txt file.Simon Pilgrim2018-09-271-1/+1
| | | | llvm-svn: 343215
* [docs] Remove reference to makellvm which was removed in rL329041Fangrui Song2018-09-271-9/+0
| | | | llvm-svn: 343165
* [llvm-exegesis] Fix doc in r342947.Clement Courbet2018-09-251-8/+9
| | | | | | llvm-exegesis.rst was using invalid indentation for bullet points. llvm-svn: 342948
* [llvm-exegesis] Allow benchmarking arbitrary code snippets.Clement Courbet2018-09-251-8/+52
| | | | | | | | | | | | | | | | | Summary: This is a step towards fixing PR38048. Note that right now the measurements are given per instruction. We'll need to give measurements a per code snippet and update the analysis (PR38731). Reviewers: gchatelet Subscribers: tschuett, llvm-commits Differential Revision: https://reviews.llvm.org/D52041 llvm-svn: 342947
* [Docs] [Support] Correct a missed reference and use up to date .inc examples.Kristina Brooks2018-09-211-10/+11
| | | | | | | | In my original diff I missed #include "llvm/System/Thing.h" and forgot to update a reference to .inc files a few lines down. This patch corrects these things as they were missed in revision 342500. llvm-svn: 342705
* [IR] Add a boolean field in DILocation to know if a line must covered or notCalixte Denizet2018-09-201-0/+15
| | | | | | | | | | | | | | | | | | | | | Summary: Some lines have a hit counter where they should not have one. For example, in C++, some cleanup is adding at the end of a scope represented by a '}'. So such a line has a hit counter where a user expects to not have one. The goal of the patch is to add this information in DILocation which is used to get the covered lines in GCOVProfiling.cpp. A following patch in clang will add this information when generating IR (https://reviews.llvm.org/D49916). Reviewers: marco-c, davidxl, vsk, javed.absar, rnk Reviewed By: rnk Subscribers: eraman, xur, danielcdh, aprantl, rnk, dblaikie, #debug-info, vsk, llvm-commits, sylvestre.ledru Tags: #debug-info Differential Revision: https://reviews.llvm.org/D49915 llvm-svn: 342631
* Improve the doc about the initial commit email sent to the MLSylvestre Ledru2018-09-201-2/+2
| | | | llvm-svn: 342622
* Remove svn:executable from a documentation file.Kristina Brooks2018-09-181-0/+0
| | | | | | Should fix the buildbot failure caused by it. llvm-svn: 342502
* [Docs] [Support] System Library to Support Library transition along with ↵Kristina Brooks2018-09-183-243/+252
| | | | | | | | | | | | minor corrections to reflect it. System Library has been a long deprecated term along with the path lib/System, having been superseded/renamed to the Support Library a long time ago. These patches reflect those changes in documentation as well as update some outdated examples and provide context to the origin of the Support Library. Differential Revision: https://reviews.llvm.org/D52107 llvm-svn: 342500
* [ThinLTO] Update LangRef doc for summary parsingTeresa Johnson2018-09-181-10/+10
| | | | | | | | | | | | | | | | | Summary: Remove note about summary being ignored. Update to reflect the fact that summary is now parsed by llvm-as. While here, fix one summary format that changed since the initial implementation. Reviewers: dexonsmith Subscribers: inglorion, llvm-commits Differential Revision: https://reviews.llvm.org/D51540 llvm-svn: 342479
* Add flag to llvm-profdata to allow symbols in profile data to be remapped, andRichard Smith2018-09-133-0/+102
| | | | | | | | | | | | | | | | | add a tool to generate symbol remapping files. Summary: The new tool llvm-cxxmap builds a symbol mapping table from a file containing a description of partial equivalences to apply to mangled names and files containing old and new symbol tables. Reviewers: davidxl Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D51470 llvm-svn: 342168
* ReleaseNotes: update links to use httpsHans Wennborg2018-09-101-8/+8
| | | | llvm-svn: 341785
* [benchmark] Re-enable benchmarks on all platforms including WindowsReid Kleckner2018-09-071-2/+1
| | | | | | | | | The assertion in MCCodeView.cpp was resolved in r340878. This reverts both r340905 and r340836, making benchmarks build by default everywhere. llvm-svn: 341716
* [x86/SLH] Add a real Clang flag and LLVM IR attribute for SpeculativeChandler Carruth2018-09-041-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Load Hardening. Wires up the existing pass to work with a proper IR attribute rather than just a hidden/internal flag. The internal flag continues to work for now, but I'll likely remove it soon. Most of the churn here is adding the IR attribute. I talked about this Kristof Beyls and he seemed at least initially OK with this direction. The idea of using a full attribute here is that we *do* expect at least some forms of this for other architectures. There isn't anything *inherently* x86-specific about this technique, just that we only have an implementation for x86 at the moment. While we could potentially expose this as a Clang-level attribute as well, that seems like a good question to defer for the moment as it isn't 100% clear whether that or some other programmer interface (or both?) would be best. We'll defer the programmer interface side of this for now, but at least get to the point where the feature can be enabled without relying on implementation details. This also allows us to do something that was really hard before: we can enable *just* the indirect call retpolines when using SLH. For x86, we don't have any other way to mitigate indirect calls. Other architectures may take a different approach of course, and none of this is surfaced to user-level flags. Differential Revision: https://reviews.llvm.org/D51157 llvm-svn: 341363
* [x86/SLH] Teach SLH to harden against the "ret2spec" attack byChandler Carruth2018-09-041-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
* Revamp test-suite documentationMatthias Braun2018-08-316-233/+428
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Remove duplication: Both TestingGuide and TestSuiteMakefileGuide would give a similar overview over the test-suite. - Present cmake/lit as the default/normal way of running the test-suite: - Move information about the cmake/lit testsuite into the new TestSuiteGuide.rst file. Mark the remaining information in TestSuiteMakefilesGuide.rst as deprecated. - General simplification and shorting of language. - Remove paragraphs about tests known to fail as everything should pass nowadays. - Remove paragraph about zlib requirement; it's not required anymore since we copied a zlib source snapshot into the test-suite. - Remove paragraph about comparison with "native compiler". Correctness is always checked against reference outputs nowadays. - Change cmake/lit quickstart section to recommend `pip` for installing lit and use `CMAKE_C_COMPILER` and a cache file in the example as that is what most people will end up doing anyway. Also a section about compare.py to quickstart. - Document `Bitcode` and `MicroBenchmarks` directories. - Add section with commonly used cmake configuration options. - Add section about showing and comparing result files via compare.py. - Add section about using external benchmark suites. - Add section about using custom benchmark suites. - Add section about profile guided optimization. - Add section about cross-compilation and running on external devices. Differential Revision: https://reviews.llvm.org/D51465 llvm-svn: 341260
* [llvm-mca] Report the number of dispatched micro opcodes in the ↵Andrea Di Biagio2018-08-301-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DispatchStatistics view. This patch introduces the following changes to the DispatchStatistics view: * DispatchStatistics now reports the number of dispatched opcodes instead of the number of dispatched instructions. * The "Dynamic Dispatch Stall Cycles" table now also reports the percentage of stall cycles against the total simulated cycles. This change allows users to easily compare dispatch group sizes with the processor DispatchWidth. Before this change, it was difficult to correlate the two numbers, since DispatchStatistics view reported numbers of instructions (instead of opcodes). DispatchWidth defines the maximum size of a dispatch group in terms of number of micro opcodes. The other change introduced by this patch is related to how DispatchStage generates "instruction dispatch" events. In particular: * There can be multiple dispatch events associated with a same instruction * Each dispatch event now encapsulates the number of dispatched micro opcodes. The number of micro opcodes declared by an instruction may exceed the processor DispatchWidth. Therefore, we cannot assume that instructions are always fully dispatched in a single cycle. DispatchStage knows already how to handle instructions declaring a number of opcodes bigger that DispatchWidth. However, DispatchStage always emitted a single instruction dispatch event (during the first simulated dispatch cycle) for instructions dispatched. With this patch, DispatchStage now correctly notifies multiple dispatch events for instructions that cannot be dispatched in a single cycle. A few views had to be modified. Views can no longer assume that there can only be one dispatch event per instruction. Tests (and docs) have been updated. Differential Revision: https://reviews.llvm.org/D51430 llvm-svn: 341055
* [llvm-mca] Add fields "Total uOps" and "uOps Per Cycle" to the report ↵Andrea Di Biagio2018-08-291-20/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | generated by the SummaryView. This patch adds two new fields to the perf report generated by the SummaryView. Fields are now logically organized into two small groups; only the second group contains throughput indicators. Example: ``` Iterations: 100 Instructions: 300 Total Cycles: 414 Total uOps: 700 Dispatch Width: 4 uOps Per Cycle: 1.69 IPC: 0.72 Block RThroughput: 4.0 ``` This patch also updates the docs for llvm-mca. Due to the nature of this change, several tests in the tools/llvm-mca directory were affected, and had to be updated using script `update_mca_test_checks.py`. llvm-svn: 340946
* [benchmark] NFC: Turn benchmark ON on all non-Windows buildbotsKirill Bobyrev2018-08-291-1/+2
| | | | | | | | | The problems with benchmark build should be fixed now, but Windows buildbots still run into errors seemingly because of the bug in clang-cl. Because of that, benchmark shouldn't be built on Windows at this point. llvm-svn: 340905
* [XRay][docs] Chrome Trace Viewer InstructionsDean Michael Berris2018-08-281-2/+16
| | | | | | | This patch adds an example on how to generate a Chrome Trace Viewer loadable trace from an XRay trace. llvm-svn: 340847
* [XRay][docs] Update instructionsDean Michael Berris2018-08-281-1/+1
| | | | | | | Add `xray_mode=xray-basic` to the list of options in the "further exploration" section of the doc. llvm-svn: 340843
* [benchmark] Stop building benchmarks by defaultKirill Bobyrev2018-08-281-1/+1
| | | | | | | | | | | | | Although the benchmark regex-related build issue seems to be fixed, it appears that benchmark library triggers some stage 2 clang-cl bugs: http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/13495/steps/build%20stage%202/logs/stdio The only sensible option now is to prevent benchmark library from building in the default configuration. llvm-svn: 340836
* Pull google/benchmark library to the LLVM treeKirill Bobyrev2018-08-281-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch pulls google/benchmark v1.4.1 into the LLVM tree so that any project could use it for benchmark generation. A dummy benchmark is added to `llvm/benchmarks/DummyYAML.cpp` to validate the correctness of the build process. The current version does not utilize LLVM LNT and LLVM CMake infrastructure, but that might be sufficient for most users. Two introduced CMake variables: * `LLVM_INCLUDE_BENCHMARKS` (`ON` by default) generates benchmark targets * `LLVM_BUILD_BENCHMARKS` (`OFF` by default) adds generated benchmark targets to the list of default LLVM targets (i.e. if `ON` benchmarks will be built upon standard build invocation, e.g. `ninja` or `make` with no specific targets) List of modifications: * `BENCHMARK_ENABLE_TESTING` is disabled * `BENCHMARK_ENABLE_EXCEPTIONS` is disabled * `BENCHMARK_ENABLE_INSTALL` is disabled * `BENCHMARK_ENABLE_GTEST_TESTS` is disabled * `BENCHMARK_DOWNLOAD_DEPENDENCIES` is disabled Original discussion can be found here: http://lists.llvm.org/pipermail/llvm-dev/2018-August/125023.html Reviewed by: dberris, lebedev.ri Subscribers: ilya-biryukov, ioeric, EricWF, lebedev.ri, srhines, dschuff, mgorny, krytarowski, fedor.sergeev, mgrang, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50894 llvm-svn: 340809
* LangRef: Clarify expected sNaN behavior for minnum/maxnumMatt Arsenault2018-08-271-10/+27
| | | | | | | This matches the de-facto behavior based on constant folding and the default lowering to fmin/fmax. llvm-svn: 340762
* [llvm-mca] Improved report generated by the SchedulerStatistics view.Andrea Di Biagio2018-08-271-7/+13
| | | | | | | | | | | | | Before this patch, the SchedulerStatistics only printed the maximum number of buffer entries consumed in each scheduler's queue at a given point of the simulation. This patch restructures the reported table, and adds an extra field named "Average number of used buffer entries" to it. This patch also uses different colors to help identifying bottlenecks caused by high scheduler's buffer pressure. llvm-svn: 340746
* [IR] Replace `isa<TerminatorInst>` with `isTerminator()`.Chandler Carruth2018-08-261-2/+2
| | | | | | | | | | | | This is a bit awkward in a handful of places where we didn't even have an instruction and now we have to see if we can build one. But on the whole, this seems like a win and at worst a reasonable cost for removing `TerminatorInst`. All of this is part of the removal of `TerminatorInst` from the `Instruction` type hierarchy. llvm-svn: 340701
* [llvm] Document "%T" as deprecated in CommandGuide/lit.rstKuba Mracek2018-08-251-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D48842 llvm-svn: 340677
* Allow creating llvm::Function in non-zero address spacesAlexander Richardson2018-08-231-8/+17
| | | | | | | | | | | | | | | | | | | | Most users won't have to worry about this as all of the 'getOrInsertFunction' functions on Module will default to the program address space. An overload has been added to Function::Create to abstract away the details for most callers. This is based on https://reviews.llvm.org/D37054 but without the changes to make passing a Module to Function::Create() mandatory. I have also added some more tests and fixed the LLParser to accept call instructions for types in the program address space. Reviewed By: bjope Differential Revision: https://reviews.llvm.org/D47541 llvm-svn: 340519
* [AArch64] Add Tiny Code Model for AArch64David Green2018-08-221-0/+1
| | | | | | | | | | | | | | This adds the plumbing for the Tiny code model for the AArch64 backend. This, instead of loading addresses through the normal ADRP;ADD pair used in the Small model, uses a single ADR. The 21 bit range of an ADR means that the code and its statically defined symbols need to be within 1MB of each other. This makes it mostly interesting for embedded applications where we want to fit as much as we can in as small a space as possible. Differential Revision: https://reviews.llvm.org/D49673 llvm-svn: 340397
* [docs][gold] Fix a typoFangrui Song2018-08-211-1/+1
| | | | llvm-svn: 340335
* [docs] Fix a small typo in a debug info exampleAlex Langford2018-08-211-1/+1
| | | | llvm-svn: 340246
* Updating MergeFunctions.rstAditya Kumar2018-08-181-191/+174
| | | | | | | | | Improving readability, removing redundant contents. Reviewers: hiraditya Differential Revision: https://reviews.llvm.org/D50686 llvm-svn: 340131
* [x86/MIR] Implement support for pre- and post-instruction symbols, asChandler Carruth2018-08-161-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | well as MIR parsing support for `MCSymbol` `MachineOperand`s. The only real way to test pre- and post-instruction symbol support is to use them in operands, so I ended up implementing that within the patch as well. I can split out the operand support if folks really want but it doesn't really seem worth it. The functional implementation of pre- and post-instruction symbols is now *completely trivial*. Two tiny bits of code in the (misnamed) AsmPrinter. It should be completely target independent as well. We emit these exactly the same way as we emit basic block labels. Most of the code here is to give full dumping, MIR printing, and MIR parsing support so that we can write useful tests. The MIR parsing of MC symbol operands still isn't 100%, as it forces the symbols to be non-temporary and non-local symbols with names. However, those names often can encode most (if not all) of the special semantics desired, and unnamed symbols seem especially annoying to serialize and de-serialize. While this isn't perfect or full support, it seems plenty to write tests that exercise usage of these kinds of operands. The MIR support for pre-and post-instruction symbols was quite straightforward. I chose to print them out in an as-if-operand syntax similar to debug locations as this seemed the cleanest way and let me use nice introducer tokens rather than inventing more magic punctuation like we use for memoperands. However, supporting MIR-based parsing of these symbols caused me to change the design of the symbol support to allow setting arbitrary symbols. Without this, I don't see any reasonable way to test things with MIR. Differential Revision: https://reviews.llvm.org/D50833 llvm-svn: 339962
OpenPOWER on IntegriCloud