similar to: LLVM deprecation policy

Oh my. You think I should patch every .td file in the system? That sounds a bit scary. I wrote a new test for range lists that tests the old and new range punctuator. And a release note is certainly in order. But I wasn't planning to patch all 600 .td files. At 8/7/2020 01:56 PM, David Blaikie wrote: >Fine by me to say the old thing's deprecated. > >Ideally, if it's not too

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

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

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

When going through the xapian bindings yesterday, I noticed that several of the methods were not wrapped for Ruby because they were deprecated at the time the ruby bindings were created. I filed a bug (#126) saying that they should be removed entirely, which led to the suggestion from Olly that it would be good to make a semi-formal policy about deprecating features. I've written such a

I was confused by the lack of TableGen backends in the llvm/lib/tablegen directory until I stumbled upon the llvm/utils/tablegen directory. Could someone explain why TableGen is divided into these two directories? ---------------------------------------------------------------- Windfall Paul C. Anagnostopoulos ----------------------------------------------------------

Olly and I have been discussing details of our policy for deprecating features, and we thought it would be useful to canvas users opinions on a particular aspect. From time to time, we remove features from the library (usually because we have a better replacement). To make life easier for users, we've been following a deprecation policy, so that users are given plenty of warning of

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

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

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

Sorry, I'm not sure what you mean. When I added the new TableGen reference a couple of weeks ago, I don't recall adding it to any list of documents. It appeared as if every document in the docs/ directories was built.

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

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

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

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

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

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?

I made a simple edit to TGlexer.h, which is part of TableGen. Then, in Visual Studio, I asked it to build Tablegen. I got the following output: 1>------ Build started: Project: LLVMTableGen, Configuration: Release x64 ------ 1>Main.cpp 1>TGLexer.cpp 1>TGParser.cpp 1>LLVMTableGen.vcxproj -> D:\LLVM\Build\Release\lib\LLVMTableGen.lib ========== Build: 1 succeeded, 0 failed, 3