similar to: TableGen enhancements

Now that I've learned my way around TableGen just a bit, I'd like to solicit suggestions for improving and enhancing it. Perhaps there are some lexical changes that could improve readability of .td files (e.g., I'm planning to enhance the lexer to allow an apostrophe as a digit group separator in integers, a la C++). Perhaps there are some syntactic enhancements that would make .td

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?

Jakob, I think this exactly what's happening. I debugged the resolveReferences for the ADD down into the resolve of TSFlags. It calls VarInit::getFieldInit for the "Val" field of "foo". The code is: Init *VarInit::getFieldInit(Record &R, const RecordVal *RV, const std::string &FieldName) const { if (isa<RecordRecTy>(getType()))

Hello, InstAlias does not allow tied operands (repeated operands) in the asm string to be matched. It seems this situation is explicitly prevented in AsmMatcherEmitter.cpp: if (!Hack) PrintFatalError(TheDef->getLoc(), "ERROR: matchable with tied operand '" + Tok + "' can never be matched!");

Hello. I am curious why did you changed TableGen to allow in principle only writing ASM instructions in prefix notation. I ask because I personally use an assembly notation that is infix (I could use a simple preprocessor that changes prefix to infix). Just to mention: I found the solution to this - the following part of the code is responsible for this from

On Jan 31, 2013, at 9:27 AM, Sean Silva <silvas at purdue.edu> wrote: > An extra call to resolveReferences after setting the value in the > `let` does fix this, but I'm not sure that it is the right fix. The > attached hackish patch seems to fix up a reduced version of the test > case you gave here (I haven't run a full battery of tests on it, so it > might cause

An extra call to resolveReferences after setting the value in the `let` does fix this, but I'm not sure that it is the right fix. The attached hackish patch seems to fix up a reduced version of the test case you gave here (I haven't run a full battery of tests on it, so it might cause other failures). Jakob, any idea about what the "right" fix is here? -- Sean Silva

It's interesting that you bring this up. I've seen a lot of TableGen error messages over the past couple of weeks and I don't recall being confused about any error or its location. I will give this a closer look. I agree that syntactic enhancements aren't particularly exciting by themselves. I was wondering whether some new features coupled with new backends would pave the way for

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

Hi, On Instructions you can use checkEarlyTargetMatchPredicate() to check that the operands are the same. There's an example of that in MipsAsmParser.cpp for DATI and DAHI. I can't think of a reason TableGen couldn't be made to allow this for InstAlias too. > On 15 Dec 2017, at 02:12, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > InstAlias

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

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,

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.

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

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’d like to propose that Paul C. Anagnostopoulos takes on the role as the code owner of TableGen. This is a critical tool in LLVM and Paul has been doing a great job making across the board upgrades to it. Any concerns? -Chris

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

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

Given that I'm only somewhat up-to-speed on the DAG ISel scheme and not much at all on the Global ISel scheme, I'm tempted to work on the former and then the latter. So I'll look at the CodeGenDAGPatterns messages first. Then I will take a look at Global ISel. Matt: Can you suggest one or two things about Global ISel that could use some work? I won't get to it quickly, but it will