similar to: Musings on the TableGen -emit-dag-isel backend

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

On 13.11.20 13:22, Paul C. Anagnostopoulos via llvm-dev wrote: > 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

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

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

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

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

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,

Would it be helpful to be able to use Doxygen on TableGen .td files?

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

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

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,

I took a look at all the OPC_SwitchOpcode operators in the matching tables. Almost every target starts with a large one, which is now cached by the interpreter. Instead, TableGen could build the opcode -> offset table. But there are also many other opcode switches with between 10 and 70 cases. To speed these up, we could embed a sorted opcode -> offset table right in the matcher code. Or,

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

A rather notorious aspect of TableGen is the time required to run the -emit-dag-isel backend on some targets, including AMDGPU and X86. I added a timing feature to TableGen and timed the AMDGPU run. ===-------------------------------------------------------------------------=== TableGen Phase Timing

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

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 great! Thanks Paul! I think that the 9x reduction in compile-time is well worth the 4% size increase. TableGen's run-time has been a sore point and a source of complaints for quite some time. -- Krzysztof Parzyszek kparzysz at quicinc.com AI tools development -----Original Message----- From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Paul C.

This is the size of the table, not the size of the overall binary, right? I would imagine that a 4% growth in the size of the table is a substantially smaller growth in the total executable size of, say, clang. If the overall growth is minuscule (say, under 1%), then this seems like the clear path forward. I’m also optimistic that we might be able to find other ways to shrink the tables to make