summaryrefslogtreecommitdiffstats
path: root/llvm/docs/TableGen
Commit message (Collapse)AuthorAgeFilesLines
* [TableGen] Introduce an if/then/else statement.Simon Tatham2020-01-141-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This allows you to make some of the defs in a multiclass or `foreach` conditional on an expression computed from the parameters or iteration variables. It was already possible to simulate an if statement using a `foreach` with a dummy iteration variable and a list constructed using `!if` so that it had length 0 or 1 depending on the condition, e.g. foreach unusedIterationVar = !if(condition, [1], []<int>) in { ... } But this syntax is nicer to read, and also more convenient because it allows an else clause. To avoid upheaval in the implementation, I've implemented `if` as pure syntactic sugar on the `foreach` implementation: internally, `ParseIf` actually does construct exactly the kind of foreach shown above (and another reversed one for the else clause if present). Reviewers: nhaehnle, hfinkel Reviewed By: hfinkel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71474
* [TableGen] Introduce a `defvar` statement.Simon Tatham2020-01-141-5/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This allows you to define a global or local variable to an arbitrary value, and refer to it in subsequent definitions. The main use I anticipate for this is if you have to compute some difficult function of the parameters of a multiclass, and then use it many times. For example: multiclass Foo<int i, string s> { defvar op = !cast<BaseClass>("whatnot_" # s # "_" # i); def myRecord { dag a = (op this, (op that, the other), (op x, y, z)); int b = op.subfield; } def myOtherRecord<"template params including", op>; } There are a couple of ways to do this already, but they're not really satisfactory. You can replace `defvar x = y` with a loop over a singleton list, `foreach x = [y] in { ... }` - but that's unintuitive to someone who hasn't seen that workaround idiom before, and requires an extra pair of braces that you often didn't really want. Or you can define a nested pair of multiclasses, with the inner one taking `x` as a template parameter, and the outer one instantiating it just once with the desired value of `x` computed from its other parameters - but that makes it awkward to sequentially compute each value based on the previous ones. I think `defvar` makes things considerably easier. You can also use `defvar` at the top level, where it inserts globals into the same map used by `defset`. That allows you to define global constants without having to make a dummy record for them to live in: defvar MAX_BUFSIZE = 512; // previously: // def Dummy { int MAX_BUFSIZE = 512; } // and then refer to Dummy.MAX_BUFSIZE everywhere Reviewers: nhaehnle, hfinkel Reviewed By: hfinkel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71407
* [Docs] Fix sphinx build errors.Florian Hahn2019-12-231-3/+3
|
* [TableGen] Add bang-operators !getop and !setop.Simon Tatham2019-12-112-1/+30
| | | | | | | | | | | | | | | | | | | | | | Summary: These allow you to get and set the operator of a dag node, without affecting its list of arguments. `!getop` is slightly fiddly because in many contexts you need its return value to have a static type more specific than 'any record'. It works to say `!cast<BaseClass>(!getop(...))`, but it's cumbersome, so I made `!getop` take an optional type suffix itself, so that can be written as the shorter `!getop<BaseClass>(...)`. Reviewers: hfinkel, nhaehnle Reviewed By: nhaehnle Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71191
* [docs] Fix TableGen/LangRef typosJordan Rupprecht2019-06-131-2/+2
| | | | | | | | This fixes: - `Pred` -> `Prep` - `IfDef` -> `Ifdef` (rst is case sensitive here) llvm-svn: 363294
* [TableGen] Introduce !listsplat 'binary' operatorRoman Lebedev2019-04-102-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: ``` ``!listsplat(a, size)`` A list value that contains the value ``a`` ``size`` times. Example: ``!listsplat(0, 2)`` results in ``[0, 0]``. ``` I plan to use this in X86ScheduleBdVer2.td for LoadRes handling. This is a little bit controversial because unlike every other binary operator the types aren't identical. Reviewers: stoklund, javed.absar, nhaehnle, craig.topper Reviewed By: javed.absar Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60367 llvm-svn: 358117
* [Tablegen] Add support for the !mul operator.Nicola Zaghen2019-03-012-2/+2
| | | | | | | | | This is a small addition to arithmetic operations that improves expressiveness of the language. Differential Revision: https://reviews.llvm.org/D58775 llvm-svn: 355187
* [TblGen][NFC] Fix documentation formattingJaved Absar2019-01-251-7/+3
| | | | llvm-svn: 352212
* [TblGen] Extend !if semantics through new feature !condJaved Absar2019-01-252-1/+23
| | | | | | | | | | | | | | | | | This patch extends TableGen language with !cond operator. Instead of embedding !if inside !if which can get cumbersome, one can now use !cond. Below is an example to convert an integer 'x' into a string: !cond(!lt(x,0) : "Negative", !eq(x,0) : "Zero", !eq(x,1) : "One, 1 : "MoreThanOne") Reviewed By: hfinkel, simon_tatham, greened Differential Revision: https://reviews.llvm.org/D55758 llvm-svn: 352185
* [TableGen] Preprocessing supportVyacheslav Zakharin2018-11-271-1/+48
| | | | | | Differential Revision: https://reviews.llvm.org/D54926 llvm-svn: 347686
* Reverted r347092 due to the following build fails:Vyacheslav Zakharin2018-11-171-48/+1
| | | | | | | http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/8662 http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/26263 llvm-svn: 347129
* Preprocessing support in tablegen.Vyacheslav Zakharin2018-11-161-1/+48
| | | | | | Differential Revision: https://reviews.llvm.org/D53840 llvm-svn: 347092
* [TableGen] Add a general-purpose JSON backend.Simon Tatham2018-07-112-2/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The aim of this backend is to output everything TableGen knows about the record set, similarly to the default -print-records backend. But where -print-records produces output in TableGen's input syntax (convenient for humans to read), this backend produces it as structured JSON data, which is convenient for loading into standard scripting languages such as Python, in order to extract information from the data set in an automated way. The output data contains a JSON representation of the variable definitions in output 'def' records, and a few pieces of metadata such as which of those definitions are tagged with the 'field' prefix and which defs are derived from which classes. It doesn't dump out absolutely every piece of knowledge it _could_ produce, such as type information and complicated arithmetic operator nodes in abstract superclasses; the main aim is to allow consumers of this JSON dump to essentially act as new backends, and backends don't generally need to depend on that kind of data. The new backend is implemented as an EmitJSON() function similar to all of llvm-tblgen's other EmitFoo functions, except that it lives in lib/TableGen instead of utils/TableGen on the basis that I'm expecting to add it to clang-tblgen too in a future patch. To test it, I've written a Python script that loads the JSON output and tests properties of it based on comments in the .td source - more or less like FileCheck, except that the CHECK: lines have Python expressions after them instead of textual pattern matches. Reviewers: nhaehnle Reviewed By: nhaehnle Subscribers: arichardson, labath, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D46054 llvm-svn: 336771
* TableGen/SearchableTables: Support more generic enums and tablesNicolai Haehnle2018-06-211-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is essentially a rewrite of the backend which introduces TableGen base classes GenericEnum, GenericTable, and SearchIndex. They allow generating custom enums and tables with lookup functions using separately defined records as the underlying database. Also added as part of this change: - Lookup functions may use indices composed of multiple fields. - Instruction fields are supported similar to Intrinsic fields. - When the lookup key has contiguous numeric values, the lookup function will directly index into the table instead of using a binary search. The existing SearchableTable functionality is internally mapped to the new primitives. Change-Id: I444f3490fa1dbfb262d7286a1660a2c4308e9932 Reviewers: arsenm, tra, t.p.northover Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D48013 llvm-svn: 335225
* TableGen: some LangRef doc fixesNicolai Haehnle2018-06-042-5/+31
| | | | | | | | | | | | | Summary: Change-Id: I1442e2daa09cab727a01d8c31893b50e644a5cd3 Reviewers: tra, simon_tatham, craig.topper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47530 Change-Id: I397655dd18b7ff978c1affa3174740d9c1a82594 llvm-svn: 333901
* TableGen: Streamline the semantics of NAMENicolai Haehnle2018-06-042-23/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The new rules are straightforward. The main rules to keep in mind are: 1. NAME is an implicit template argument of class and multiclass, and will be substituted by the name of the instantiating def/defm. 2. The name of a def/defm in a multiclass must contain a reference to NAME. If such a reference is not present, it is automatically prepended. And for some additional subtleties, consider these: 3. defm with no name generates a unique name but has no special behavior otherwise. 4. def with no name generates an anonymous record, whose name is unique but undefined. In particular, the name won't contain a reference to NAME. Keeping rules 1&2 in mind should allow a predictable behavior of name resolution that is simple to follow. The old "rules" were rather surprising: sometimes (but not always), NAME would correspond to the name of the toplevel defm. They were also plain bonkers when you pushed them to their limits, as the old version of the TableGen test case shows. Having NAME correspond to the name of the toplevel defm introduces "spooky action at a distance" and breaks composability: refactoring the upper layers of a hierarchy of nested multiclass instantiations can cause unexpected breakage by changing the value of NAME at a lower level of the hierarchy. The new rules don't suffer from this problem. Some existing .td files have to be adjusted because they ended up depending on the details of the old implementation. Change-Id: I694095231565b30f563e6fd0417b41ee01a12589 Reviewers: tra, simon_tatham, craig.topper, MartinO, arsenm, javed.absar Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D47430 llvm-svn: 333900
* Fix BNF nits in TableGen language reference.Simon Tatham2018-04-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In the course of writing an experimental ANTLR grammar based on this document, I found three errors in the documented BNF: SimpleValues of dag type are allowed to have no operands at all after the initial DagArg specifying the operator. For example, the value (outs) is extremely common in backends; an example in the test suite is test/TableGen/AsmVariant.td line 30. But the BNF doesn't allow DagArgList to expand to the empty string (it must contain at least one DagArg), and therefore the DagArgList specifying the operands in the dag-shaped production for SimpleValue should be optional. In the production for BodyItem with a 'let' and an optional RangeList, the RangeList should have braces around it if it's present, matching code such as "let E{7-0} = ..." on test/TableGen/BitsInit.td line 42. Those braces aren't included in the RangeList nonterminal itself, so instead they need to be part of the optional segment of the BodyItem production. Finally, the identifier after 'defm' should be optional. Again, this is very common in the real back end .td files; an example in the test suite is in test/TableGen/defmclass.td line 49. Reviewers: rengolin, nhaehnle, stoklund Reviewed By: nhaehnle Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45818 llvm-svn: 330570
* Test commit access.Simon Tatham2018-04-231-1/+1
| | | | | | | | | | | Should be a harmless trimming of trailing whitespace from a documentation file. (There are other instances of trailing whitespace in this file alone. I've only fixed one of them, on the basis that that way the rest are still available for other people's commit-access tests :-) llvm-svn: 330567
* TableGen: Remove the cast-from-string-to-variable-reference featureNicolai Haehnle2018-03-191-4/+0
| | | | | | | | | | | | | | | | | | | Summary: Cast-from-string for records isn't going away, but cast-from-string for variables is a pretty dodgy feature to have, especially when referencing template arguments. It's doubtful that this ever worked in a reliable way, and nobody seems to be using it, so let's get rid of it and get some related cleanups. Change-Id: I395ac8a43fef4cf98e611f2f552300d21e99b66a Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44195 llvm-svn: 327844
* TableGen: Add !ne, !le, !lt, !ge, and !gt comparisonsNicolai Haehnle2018-03-142-1/+9
| | | | | | | | Change-Id: I8e2ece677268972d578a787467f7ef52a1f33a71 Differential revision: https://reviews.llvm.org/D44114 llvm-svn: 327496
* TableGen: Type-check BinOpsNicolai Haehnle2018-03-141-2/+6
| | | | | | | | | | | Additionally, allow more than two operands to !con, !add, !and, !or in the same way as is already allowed for !listconcat and !strconcat. Change-Id: I9659411f554201b90cd8ed7c7e004d381a66fa93 Differential revision: https://reviews.llvm.org/D44112 llvm-svn: 327494
* TableGen: Allow ? in listsNicolai Haehnle2018-03-141-3/+3
| | | | | | | | | | This makes using !dag more convenient in some cases. Change-Id: I0a8c35e15ccd1ecec778fd1c8d64eee38d74517c Differential revision: https://reviews.llvm.org/D44111 llvm-svn: 327493
* TableGen: Add !dag function for constructionNicolai Haehnle2018-03-142-1/+19
| | | | | | | | | | | | | | | This allows constructing DAG nodes with programmatically determined names, and can simplify constructing DAG nodes in other cases as well. Also, add documentation and some very simple tests for the already existing !con. Change-Id: Ida61cd82e99752548d7109ce8da34d29da56a5f7 Differential revision: https://reviews.llvm.org/D44110 llvm-svn: 327492
* TableGen: Add a defset statementNicolai Haehnle2018-03-091-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | Allows capturing a list of concrete instantiated defs. This can be combined with foreach to create parallel sets of def instantiations with less repetition in the source. This purpose is largely also served by multiclasses, but in some cases multiclasses can't be used. The motivating example for this change is having a large set of intrinsics, which are generated from the IntrinsicsBackend.td file included by Intrinsics.td, and a corresponding set of instruction selection patterns, which are generated via the backend's .td files. Multiclasses cannot be used to eliminate the redundancy in this case, because a multiclass cannot span both LLVM's common .td files and the backend .td files at the same time. Change-Id: I879e35042dceea542a5e6776fad23c5e0e69e76b Differential revision: https://reviews.llvm.org/D44109 llvm-svn: 327121
* TableGen: Allow arbitrary list values as ranges of foreachNicolai Haehnle2018-03-091-2/+6
| | | | | | | | | The changes to FieldInit are required to make field references (Def.field) work inside a ForeachDeclaration: previously, Def.field wasn't resolved immediately when Def was already a fully resolved DefInit. Change-Id: I9875baec2fc5aac8c2b249e45b9cf18c65ae699b llvm-svn: 327120
* TableGen: add !isa operationNicolai Haehnle2018-03-092-0/+4
| | | | | | | | Change-Id: Iddb724c3ae706d82933a2d82c91d07e0e36b30e3 Differential revision: https://reviews.llvm.org/D44105 llvm-svn: 327117
* TableGen: Add !foldl operationNicolai Haehnle2018-03-062-1/+10
| | | | | Change-Id: I63d67bf6e0b315e2d3360e47e3b62c9517f38987 llvm-svn: 326790
* TableGen: Allow !cast of records, cleanup conversion machineryNicolai Haehnle2018-03-061-4/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Distinguish two relationships between types: is-a and convertible-to. For example, a bit is not an int or vice versa, but they can be converted into each other (with range checks that you can think of as "dynamic": unlike other type checks, those range checks do not happen during parsing, but only once the final values have been established). Actually converting initializers between types is subtle: even when values of type A can be converted to type B (e.g. int into string), it may not be possible to do so with a concrete initializer (e.g., a VarInit that refers to a variable of type int cannot be immediately converted to a string). For this reason, distinguish between getCastTo and convertInitializerTo: the latter implements the actual conversion when appropriate, while the former will first try to do the actual conversion and fall back to introducing a !cast operation so that the conversion will be delayed until variable references have been resolved. To make the approach of adding !cast operations to work, !cast needs to fallback to convertInitializerTo when the special string <-> record logic does not apply. This enables casting records to a subclass, although that new functionality is only truly useful together with !isa, which will be added in a later change. The test is removed because it uses !srl on a bit sequence, which cannot really be supported consistently, but luckily isn't used anywhere either. Change-Id: I98168bf52649176654ed2ec61a29bdb29970cfe7 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43753 llvm-svn: 326785
* TableGen: Reimplement !foreach using the resolving mechanismNicolai Haehnle2018-03-051-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This changes the syntax of !foreach so that the first "parameter" is a new syntactic variable: !foreach(x, lst, expr) will define the variable x within the scope of expr, and evaluation of the !foreach will substitute elements of the given list (or dag) for x in expr. Aside from leading to a nicer syntax, this allows more complex expressions where x is deeply nested, or even constant expressions in which x does not occur at all. !foreach is currently not actually used anywhere in trunk, but I plan to use it in the AMDGPU backend. If out-of-tree targets are using it, they can adjust to the new syntax very easily. Change-Id: Ib966694d8ab6542279d6bc358b6f4d767945a805 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits, tpr Differential Revision: https://reviews.llvm.org/D43651 llvm-svn: 326705
* TableGen: Add !size operationNicolai Haehnle2018-02-232-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Returns the size of a list. I have found this to be rather useful in some development for the AMDGPU backend where we could simplify our .td files by concatenating list<LLVMType> for complex intrinsics. Doing so requires us to compute the position argument for LLVMMatchType. Basically, the usage is in a pattern that looks somewhat like this: list<LLVMType> argtypes = !listconcat(base, [llvm_any_ty, LLVMMatchType<!size(base)>]); Change-Id: I360a0b000fd488d18bea412228230fd93722bd2c Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits, tpr Differential Revision: https://reviews.llvm.org/D43553 llvm-svn: 325883
* Improvements to TableGen/LangIntro.rstAlex Bradbury2017-05-021-2/+7
| | | | | | | | | | | Document the 'code' data type, and that value{15-17} is different to value{17-15}. Patch by @chenwj (Wei-Ren Chen). Differential Revision: https://reviews.llvm.org/D32117 llvm-svn: 301920
* [X86][AVX512] Adding new LLVM TableGen backend which generates the EVEX2VEX ↵Ayman Musa2017-03-071-0/+6
| | | | | | | | | | | | compressing tables. X86EvexToVex machine instruction pass compresses EVEX encoded instructions by replacing them with their identical VEX encoded instructions when possible. It uses manually supported 2 large tables that map the EVEX instructions to their VEX ideticals. This TableGen backend replaces the tables by automatically generating them. Differential Revision: https://reviews.llvm.org/D30451 llvm-svn: 297127
* [Docs][TableGen] Remove reference to tablegen supporting octal integers. It ↵Craig Topper2016-11-181-3/+0
| | | | | | doesn't and hasn't for at least 9 years. llvm-svn: 287299
* TableGen: Add operator !orMatt Arsenault2016-11-151-1/+3
| | | | llvm-svn: 286936
* [docs] Fixing Sphinx warnings to unclog the buildbotRenato Golin2016-07-202-19/+19
| | | | | | | | | | | | | | | | | | | | | | | Lots of blocks had "llvm" or "nasm" syntax types but either weren't following the syntax, or the syntax has changed (and sphinx hasn't keep up) or the type doesn't even exist (nasm?). Other documents had :options: what were invalid. I only removed those that had warnings, and left the ones that didn't, in order to follow the principle of least surprise. This is like this for ages, but the buildbot is now failing on errors. It may take a while to upgrade the buildbot's sphinx, if that's even possible, but that shouldn't stop us from getting docs updates (which seem down for quite a while). Also, we're not losing any syntax highlight, since when it doesn't parse, it doesn't colour. Ie. those blocks are not being highlighted anyway. I'm trying to get all docs in one go, so that it's easy to revert later if we do fix, or at least easy to know what's to fix. llvm-svn: 276109
* Fixing a few places in this doc which look like obvious typos.Yunzhong Gao2016-07-201-4/+5
| | | | llvm-svn: 276070
* fix some various typos in the docSylvestre Ledru2016-07-021-1/+1
| | | | llvm-svn: 274449
* Rename all references to old mailing lists to new lists.llvm.org address.Tanya Lattner2015-08-052-2/+2
| | | | llvm-svn: 243999
* [TableGen] Correct the documentation for 'foreach' in the Language Intro.Craig Topper2015-06-061-1/+1
| | | | llvm-svn: 239204
* Remove neverHasSideEffects support from TableGen CodeGenInstruction. ↵Craig Topper2014-11-261-1/+0
| | | | | | Everyone should use hasSideEffects now. llvm-svn: 222809
* Fix typo in TableGen documentationJonathan Roelofs2014-10-031-1/+1
| | | | llvm-svn: 219018
* Document !and. Fix !shl and friends -- they provide binary operations.Joerg Sonnenberger2014-09-032-3/+3
| | | | llvm-svn: 217034
* Reinstate "Nuke the old JIT."Eric Christopher2014-09-021-2/+1
| | | | | | | | Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reinstates commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 216982
* Temporarily Revert "Nuke the old JIT." as it's not quite ready toEric Christopher2014-08-071-1/+2
| | | | | | | | | | | be deleted. This will be reapplied as soon as possible and before the 3.6 branch date at any rate. Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reverts commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 215154
* Nuke the old JIT.Rafael Espindola2014-08-071-2/+1
| | | | | | | | | I am sure we will be finding bits and pieces of dead code for years to come, but this is a good start. Thanks to Lang Hames for making MCJIT a good replacement! llvm-svn: 215111
* Update Tablegen documents given that binary literals are now sizedPete Cooper2014-08-072-3/+10
| | | | llvm-svn: 215088
* Fix typos in comments and docJF Bastien2014-08-051-1/+1
| | | | | | Committing http://reviews.llvm.org/D4798 for Robin Morisset (morisset@google.com) llvm-svn: 214934
* Fix Sphinx warnings.Dan Liew2014-07-211-4/+1
| | | | llvm-svn: 213559
* [TableGen] Allow shift operators to take bits<n>Adam Nemet2014-07-171-0/+6
| | | | | | | | | | | | | | | Convert the operand to int if possible, i.e. if the value is properly initialized. (I suppose there is further room for improvement here to also peform the shift if the uninitialized bits are shifted out.) With this little change we can now compute the scaling factor for compressed displacement with pure tablegen code in the X86 backend. This is useful because both the X86-disassembler-specific part of tablegen and the assembler need this and TD is the natural sharing place. The patch also adds the missing documentation for the shift and add operator. llvm-svn: 213277
* [tablegen] Add !listconcat operator with the similar semantics as !strconcatDaniel Sanders2014-05-072-1/+7
| | | | | | | | | | | | | | | | | | | | Summary: It concatenates two or more lists. In addition to the !strconcat semantics the lists must have the same element type. My overall aim is to make it easy to append to Instruction.Predicates rather than override it. This can be done by concatenating lists passed as arguments, or by concatenating lists passed in additional fields. Reviewers: dsanders Reviewed By: dsanders Subscribers: hfinkel, llvm-commits Differential Revision: http://reviews.llvm.org/D3506 llvm-svn: 208183
OpenPOWER on IntegriCloud