search for: hnle

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

...also appears to be the case that a record is created and bound to its name before fields are inherited from its superclasses, which is why you can write: class A <dag d> { dag the_dag = d; } def rec1 : A<(ops rec1)> Do I understand that correctly? At 8/4/2020 05:38 PM, Nicolai Hähnle wrote: >On Tue, Aug 4, 2020 at 11:13 PM Paul C. Anagnostopoulos ><paul at windfall.com> wrote: >> 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 bei...

...e 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 summary of the phases? At 8/4/2020 05:01 PM, Nicolai Hähnle wrote: >On Mon, Aug 3, 2020 at 6:04 PM Paul C. Anagnostopoulos via llvm-dev ><llvm-dev at lists.llvm.org> wrote: >> 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 state...

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 linear list of cases, often hu...

...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, Nicolai Hähnle wrote: >> >On Mon, Oct 12, 2020 at 7:37 PM Paul C. Anagnostopoulos >> ><paul at windfall.com> wrote: >> >> 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 opera...

...aving 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 DAGs have it all down in their minds by position anyway. At 10/12/2020 12:40 PM, Nicolai Hähnle wrote: >Hi Paul, > >On Sun, Oct 11, 2020 at 4:55 PM Paul C. Anagnostopoulos via llvm-dev ><llvm-dev at lists.llvm.org> wrote: >> This is a proposal to enhance TableGen's ability to analyze and manipulate >> DAGs. Hopefully this will allows more complex DAGs to be b...

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

...n 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, Nicolai Hähnle wrote: >On Mon, Oct 12, 2020 at 7:37 PM Paul C. Anagnostopoulos ><paul at windfall.com> wrote: >> 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 rath...

...c for this. Debugging Tablegen has always been a nightmare and I don't think we can ever reach a stage where we can start a debugger and debug statements in .td files step-by-step. This is far from reality unless we fundamentally change the language. On Wed, Aug 5, 2020 at 1:32 PM Nicolai Hähnle via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Wed, Aug 5, 2020 at 1:08 AM Paul C. Anagnostopoulos > <paul at windfall.com> wrote: > > Are all the records collected as they are parsed, with template > parameter substitution and lets, and *then*, after all records...

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?

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

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

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

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,

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