In D60169#1473057, @rnk wrote:

The change to merge them is quite large. I wonder if it would be simpler to handle this like we handle clang/Sema+Parse. Aren't those also circularly dependent?

Phabricator is being too smart for its own good. The main discussion of this change was over on https://reviews.llvm.org/D60169 I was creating this as a separate diff so people can see different solutions to the problem.

This is following Craig's suggestion to merge InstPrinter into MCTargetDesc, which Hexagon already does. Do people like this solution better?

That's correct, SystemZ doesn't appear to have a dependency problem. Any changes to it will be for maintaining consistency across backends.

I think having a project that has a clean dependency graph is a worthwhile goal in itself. The circular dependency here is small, and I'm not aware of a build system that can't handle it, but some do complain about it.
The other goal is consistency of the backends. As Craig mentioned, Hexagon has a small break from the other backends by merging InstPrinter and MCTargetDesc. Having the same library rules across backends would make it less confusing.

I had assumed that there was some reason to have a library separation between InstPrinter and MCTargetDesc. Merging libraries together would fix the circular dependency, although I would like to know if there is a good reason to keep these two apart.

In D60169#1456698, @craig.topper wrote:

I doubt most targets have a Utils library that you can sink a header into. What is the plan for other targets?

Sounds like this is good with a comment on the IRDescription. I'll commit this for now and leave the suggestions for follow-ups. There's two follow-ups if any is interested in perusing:

Removed the virtual function from Pass. Use OptPassGate::isEnabled to gate the construction of the strings on the caller side.

Change void pointers to llvm::Any. Update some functions to fix const issues.

Last time, this was brought up, passing strings was deemed too expensive since it would cause a string to be created every time:
http://lists.llvm.org/pipermail/llvm-dev/2018-March/122032.html

LGTM

Looking through other classes, I see that it is common to use an anchor() method as the vtable anchor. I think having it that way makes it more clear what the purpose of the out-of-line function definition is.

Well, learned something new today. I'll follow up with something that doesn't mess with the vtable anchors.