similar to: Organization of LLVM utilities

Could you expand on this a bit? I see from my build directory that llvm-tblgen.exe was built before the Target/* .inc files. It sounds like you're saying that something has to be built between the .exe and the .inc files. At 8/4/2020 02:44 PM, Chris Lattner wrote: >> On Aug 4, 2020, at 11:31 AM, Paul C. Anagnostopoulos via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>

Folks, I am interested in contributing to LLVM in the future. Meanwhile, I am reading many of the project documents (right now, "TableGen Language Reference"). Is there a way I can contribute corrections to these documents without cloning and building LLVM? ~~ Paul ---------------------------------------------------------------- Windfall Paul C. Anagnostopoulos

Just a poke to see if anyone knows when the Doxygen pages are built. ---------------------------------------------------------------- Windfall Paul C. Anagnostopoulos ---------------------------------------------------------- Software 978 369-0839 www.windfall.com ---------------------------------------------------------------- My

Can you explain how to revert for someone who is a 2 on a git scale of 0 to 10? At 9/22/2020 03:51 PM, Arthur Eubanks wrote: >Yes, push whatever is needed to fix the build if the fix is fairly simple (else revert and get an LGTM with the fix). > >Next time I'd recommend creating and pushing a revert first if you can't quickly figure out the issue.

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,

This morning I did a build with Ninja, which mysteriously decided to rebuild the entire system (something about a deps stamp being corrupted). When it was done, I had a new llvm-tblgen.exe, but all the target .inc files were old. Hmm. So I touched one of the TableGen source files and did another build. Again, a new llvm-tblgen.exe but no new .inc files. I do, however, have a new .inc.d file

John, I'm pretty much down to details and smoothing the text. Here is a pdf. Can you mark it with comments? Or you can send an email with a list. I will incorporate your comments and send you a second proof, so you can be sure I understood you. Is a week long enough? ~~ Paul At 8/5/2020 02:16 PM, John Byrd wrote: >I'd like to collaborate, if you point me at your tree. Like you,

Thank you for driving this Paul, I agree that it is better to have one doc on TableGen. This has been a point of confusion for me as well - when I land in the wrong one and can’t find what I’m looking for :-). -Chris > On Jul 31, 2020, at 1:49 PM, Paul C. Anagnostopoulos via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thanks, David. I have started a new document titled

I wasn't sure how to respond to John Byrd's post, since it wasn't addressed to me. So I've responded to Nicolai's. I'm reasonably far along in the process of writing a new Programmer's Guide for TableGen. I will continue working on it and submit it for review. I expect to do some rewriting as a result. John: Would you like me to respect a copyright on your documents

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

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

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'm pondering a new timing feature for TableGen and am wondering whether anyone uses the existing -time-regions option. Some instrumentation for it appears in CodeGenTarget.cpp and GICombinerEmitter.cpp but nowhere else. If no one is using it, I'll be tempted to remove it.

Okay, I've got two patches ready to fix my two problems. Do I simply make another commit and push it?

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 think I understand the concepts, but I sure would appreciate a specific example, and I appreciate the offer. To make your life harder, could you start with what I should do given that I have not created a branch for the first patch? I just have the six files staged. I have GitHub Desktop installed, if that makes any of the steps easier. Thanks again, and no rush! At 8/10/2020 10:07 AM,

I have submitted a patch to Phabricator that includes the TableGen file TGparser.cpp. Now I want to fix a bug in that file. What is the proper procedure so that the two patches don't get screwed up, either in my repository or in the master repository? Please answer as if I'm a git/Phabricator idiot, because, well, I am. I should note that all I did in my repository for the first patch was

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 think I could stomach changing the tests over time, although at least one should be left with the old punctuator. It's the "real" .td files that scare me. Tell me more abut diffing the test files. I assume that the CHECK: lines are checking the important results of each .td file, and so if all the tests still pass, things are good. Are you suggesting some way of automating the

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