similar to: TableGen trace facility

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

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

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

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

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

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

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,

Hi Dominik, Thanks for your reply. In my case, the Defs is the cause of the problem. Or rather, it is part of the problem, because when I remove it from the instruction TableGen gives me a different error message which concerns a part which is deeper into the pattern tree, so at least it is able to proceed beyond that part of the pattern. I have also stepped TableGen inside gdb and

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: >>

Hi, I am in the process of porting our target to GlobalISel, and have encountered a problem. Nearly all instructions in our instruction set make modifications to a CC register, and hence are defined as follows: let ..., Defs = [CCReg] in def shfts_a32_imm7: Instruction<(outs OurRC:$dst), ...>; What's more, many of these instructions have patterns where the instruction itself

Hi Daniel, Thanks for replying; I was hoping to get in touch with you on this issue. I had a look at how SelectionIDAG does it when generating the matcher table, and it does consider the implicit defs as additional output. Here is the match table generated for the pattern: /* 0*/ OPC_CheckOpcode, TARGET_VAL(ISD::SIGN_EXTEND), /* 3*/ OPC_MoveChild0, /* 4*/ OPC_CheckOpcode,

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> >

Would it be helpful to be able to use Doxygen on TableGen .td 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?

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

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

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?

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

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 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