This is an archive of the discontinued LLVM Phabricator instance.

[docs] Document how to debug instruction scheduling model generation
ClosedPublic

Authored by joelkevinjones on Jul 6 2017, 7:58 AM.

Details

Summary

Describe:

+ Exact tablegen command and how to get it
+ tablegen command debug option for subtarget generation
+ Use of schedcover.py on the debug output to determine coverage

Diff Detail

Repository
rL LLVM

Event Timeline

joelkevinjones created this revision.Jul 6 2017, 7:58 AM

Used complete file diff

christof edited edge metadata.Jul 11 2017, 5:28 AM

Good idea to add a little write-up on that utility. Might want to make it more clear that it is about the machine scheduler models. It does not do anything for the Itinerary based schedule models.

I tend not to use the make output to construct the TableGen command as it is easy enough to construct and it saves some digging into the make output to get the right command out. At the root of the source tree it is:

<build>/bin/llvm-tblgen -I include -I lib/Target/<target> lib/Target/<target>/<target>.td --gen-subtarget --debug-only=subtarget-emitter

Where <build> is the build directory and <target> the directory name of the target.

But a verbose make run does work as well if you prefer that. I don't hold a strong opinion on it.

If you know the command, I agree that digging through the verbose make output is unnecessary. I'll give the entire command and make your suggested change vis-a-vis distinguishing itinerary and machine scheduler model.

joelkevinjones edited the summary of this revision. (Show Details)

Describe distinction between sched model and itinerary vis-a-vis schedcover.py.
Give complete command for llvm-tblgen debug output

Please make sure that the build directory is not assumed to be present in the root of the source tree. For the rest I'm happy to approve it.

docs/WritingAnLLVMBackend.rst
1038

This assumes the <build> directory is at the top of the source directory. That is not true in general.

1040

Any particular reason to write to the result there? I would go for -o /dev/null because we are not interested in the generated C output.

Remove assumption that the build directory is a subdirectory of the source directory.

christof accepted this revision.Jul 19 2017, 2:20 AM
This revision is now accepted and ready to land.Jul 19 2017, 2:20 AM
This revision was automatically updated to reflect the committed changes.