This is an archive of the discontinued LLVM Phabricator instance.

[TableGen] New backend to print fully detailed records
ClosedPublic

Authored by Paul-C-Anagnostopoulos on Sep 30 2020, 11:06 AM.

Details

Summary

This new TableGen backend, invoked with --print-detailed-records, prints all the details about the global variables, classes, and records in a TableGen file. It includes more details than the default backend.

The "TableGen Backend Developer's Guide" is updated to describe this new backend.

Add a function to the SourceMgr class to get a string with a source location formatted in the standard way.

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptSep 30 2020, 11:06 AM
Paul-C-Anagnostopoulos requested review of this revision.Sep 30 2020, 11:06 AM

I have addressed all the pertinent Lint comments.

Looks nice to me, please tidy up the SourceMgr stuff and I'll take another look.

llvm/lib/Support/SourceMgr.cpp
207

Is it standard to drop the path prefix? Is this what happens when sourcemgr emits errors and warning diagnostics?

210

Shouldn't this also include column numbers?

Making this utility accessible to other clients of SourceMgr is nice, but if so, please change SourceMgr itself to use it for its internal formatting of the location information. This ensures that things stay consistent.

llvm/lib/Support/SourceMgr.cpp
207

No, it is not dropped in messages. However, it adds horrible clutter to the detailed record report, since the paths can be long. I convinced myself that there will rarely, if ever, be a duplicate filename and so the source locations will be clear.

(Check the examples above and picture them with much longer filenames.)

210

While testing the new backend, I found the column numbers to be of no use. The primary purpose of showing the source locations is to help people figure out the path that a record or field took through all the TableGen definitions. Knowing the column number of, say, the value of a field is no more useful than knowing the line number of its definition.

I will investigate using this new function in the SourceMgr itself.

lattner added inline comments.Oct 1 2020, 9:58 AM
llvm/lib/Support/SourceMgr.cpp
210

Ok, no problem. This just means that this method isn't a general "SourceMgr::getFormattedLocation" method, it is something specific to the tblgen backend. Please move it there, and the concern is addressed, thanks!

llvm/lib/Support/SourceMgr.cpp
210

The formatting of messages is already spread between a SourceMgr function and an SMDiagnostic function. The latter is the most general one, but it writes directly to a stream rather than returning a string. So I don't think the new function is contributing much to the confusion. I will, however, add a comment about this.

One solution is to write an SMDiagnostic low-level message formatter that returns a string, then use it everywhere. However, that requires you to create an SMDiagnostic instance just to format a location. So perhaps the work should be done by a new SMLoc function. The point is that there are SMLoc formatting requirements that have nothing to do with diagnostic messages.

I have added this issue to my list of things to investigate.

llvm/lib/Support/SourceMgr.cpp
210

It would be general if I add a second optional argument to include the column number. Then it can format a source location in the full style, or in various abbreviated styles.

I put the function in SourceMgr so that the new backend wouldn't directly call such functions as FindBufferContaining and GetBufferInfo. Let me check something . . .

So, only two existing TableGen backends call those functions directly: CTagsEmitter and DAGIselMatcherEmitter. So I propose to (1) create this new function we're discussing; (2) use it in those two backends; (3) then address the idea of one general-purpose location formatter.

Further investigation reveals that every every backend that prints source locations does not include the line offset. Further, PrintIncludeStack(), in the source manager itself, also does not include the line offset. So I am going to leave this new function without the line offset.

Once this patch is pushed, I will find all those places and change them to use this new function. That cleans away a bunch of uses of lower-level SourceMgr functions.

Then I will ponder what we really want for a universal source file location formatter.

I changed SourceMgr::getFormattedLocation() to getFormattedLocationNoOffset() to make it clear and to save the former name for a possible general source location formatter.

I will push this patch on Friday.

This revision is now accepted and ready to land.Oct 3 2020, 7:45 AM