similar to: Doxygen for TableGen files

Let's say I wanted to start writing a document on how to create a backend for TableGen. Such a document is suggested in "TableGen Backends." Should I describe the classes that are available to the backend in detail, or should I spend time updating the Doxygen comments in the class header files and simply present an overview in the document?

I certainly agree that there are a boatload of CMake options. I haven't even scratched the surface. In keeping with your suggestion: Is there a way to tell Ninja to build just one target machine? At 10/7/2020 02:58 PM, Nicolai Hähnle wrote: >Hi Paul, > >On Wed, Oct 7, 2020 at 3:33 PM Paul C. Anagnostopoulos via llvm-dev ><llvm-dev at lists.llvm.org> wrote: >>

Are all the records collected as they are parsed, with template parameter substitution and lets, and *then*, after all records are collected, a "pass" is made to calculate the inter-field expressions? Once I understand this, I will add a section to the new guide to explain it. I presume it is the case that this behavior should be publicized. It also appears to be the case that a record

Yes, I understand the problem. To be more useful, TableGen would have to carry the traces along with the classes and records and (re)display the values while the substitutions are being made. I'm writing a new Programmer's Guide for TableGen and have been digging into the parse-time versus substitution-time issue. I haven't found a document that makes it clear. Can you give a quick

Your suggestion for two passes is indeed my plan if simply using 3-byte sizes is not acceptable. I don't want to duplicate all the logic in a second length-calculating function, so I would just have special logic for the three matching operators with children and use the existing function for the rest, passing a null output stream. Or I could conditionalize all the output on another function

On Tue, Oct 13, 2020 at 10:47 AM Madhur Amilkanthwar <madhur13490 at gmail.com> wrote: > What do you guys think about the below enhancements? > > 5. !getdagrestype(dag [, index]) - Returns type of result value. If the DAG computes multiple values then return type of 'index'th result. > > 6. !setdagrestype(dag target_dag, type T [, index]) - Set return type of

I included the ability to get/set an operand by name because I thought it would be easier to copy+modify an existing DAG by specifying the name of the operand you want to replace rather than having to remember its position. For example, if you want to replace the first source, isn't it easier to specify $src than remember it's the second operand? Perhaps the people actually coding these

The is a syntax quirk in TableGen. A leading plus or minus sign on a decimal integer is considered part of the integer token. Coupled with this, the hyphen (-) is used to indicate integer ranges, as in '1-5'. But the compiler lexes '1-5' as '1' followed by '-5', so a special rule is required to treat that as a range. It is documented as follows: "The peculiar

I understood that the name is a matching tag for the operand and not its name (as in named macro or function arguments). However, I was assuming that the names in any one DAG node had to be unique and so could serve as selectors for operands. But a quick investigation shows that I was wrong: names can be duplicated in the same node. So DAG indexes are integers only. At 10/12/2020 01:46 PM,

I'm glad you find it useful. I haven't thought about it being done as part of the build, nor am I any sort of build guru. What do other people think? At 10/7/2020 08:12 AM, Nemanja Ivanovic wrote: >This is really useful. Is there a way to produce this output automatically (by providing some CMake variable)? For example, something like: >-DBUILD_TBLGEN_DEBUG=<Target> >

A question for those of you who have developed complex TableGen files: Do you think a trace facility would be useful during debugging? The idea is to add a new statement to TableGen along these lines: trace tag : value1, value2, ... ; When encountered, the TableGen parser would display the tag along with the values of the specified value1, value2, etc. The tag is an identifier that makes it

I had another idea for a TableGen tracing feature and would like some feedback. It's quite possible I'm on the wrong track here and that improved backend tracing is what folks really need. The idea is to add a -trace option to the tblgen command line. With it you can list one or more record names. TableGen would produce a detailed trace of how the record is built: class inheritances,

Each of the main TableGen files for the supported targets includes include "llvm/Target/Target.td" In turn, Target.td includes include "llvm/IR/Intrinsics.td" The final lines of Instrinsics.td are include "llvm/IR/IntrinsicsPowerPC.td" include "llvm/IR/IntrinsicsX86.td" include "llvm/IR/IntrinsicsARM.td" include

This is a proposal to enhance TableGen's ability to analyze and manipulate DAGs. Hopefully this will allows more complex DAGs to be built in TableGen. 1. Add a new value suffix. value(index) The value must be a DAG. The index specifies the operator or an operand, whose value is produced. The index can be 0 produce the operator 1...n produce operand by

Would it make sense for TableGen to generate the outer OPC_SwitchOpcode offset table? At 11/13/2020 07:53 AM, Nicolai Hähnle wrote: >That said, if we are seriously thinking about the performance of the byte code, perhaps some of these opcodes should be reconsidered at a higher level anyway. > >For example: The overall bytecode always begins with an OPC_SwitchOpcode implemented as a

I hacked around a bit with the simple case of tracing just classes and defs (no multiclasses or defms). Below you will see my test file and then the output produced. Note that the regular output from the PrintRecords backend follows the trace, so you can see the final classes and records there. Once the trace can be selective, it makes sense to add another option for PrintRecords that restricts

Oh yes, I am diffing the output of some of the tests in order to be sure everything is the same. And running the tests, too. I have a question about the release notes. The current version of LLVM is 10. There are release notes for 12. What happened to poor old version 11? At 8/7/2020 02:55 PM, David Blaikie wrote: >On Fri, Aug 7, 2020 at 11:47 AM Paul C. Anagnostopoulos ><paul at

Hi Paul, If all you care about is debugging then for now we can just emit a few more debug messages which would help to "trace" the flow. To distinguish traces you can prefix it with some known string. I don't think you really need a 'trace' tag in the language spec for this. Debugging Tablegen has always been a nightmare and I don't think we can ever reach a stage where

A question for all you TableGen aficionados: Does anyone know why the collection of RecordVal field values stored in a Record are represented by a SmallVector rather than some sort of map? This means that every time a record field is looked up by name, a linear search is performed. Is it a question of RAM usage?

Well, I was hinting at LLVM_DEBUG messages. You can pretty much dump all "actions" Tablegen would take to process a .td file, which should suffice, IMO. On Wed, Aug 5, 2020 at 5:59 PM Paul C. Anagnostopoulos <paul at windfall.com> wrote: > Your reply suggests that there is a way to see debug messages from > TableGen. Is that what you meant? If so, can you explain how that