Motivated by D73835, where IRBuilder becomes no longer trivially copyable, but I think this also makes sense independently. Currently, it seems that the IRBuilder copy constructor is usually used by accident, not by intention. In rG7c362b25d7a9 I've fixed a number of cases where functions accepted IRBuilder rather than IRBuilder &, thus performing an unnecessary copy. In rG5f7b92b1b4d6 I've fixed cases where an IRBuilder was copied, while an InsertPointGuard should have been used instead.
The only non-trivial use of the copy constructor is the getIRBForDbgInsertion() helper, for which I separated construction and setting of the insertion point in this patch.
Does this make sense?
Subclassing does not feel like the right approach for this (we might think about marking IRBuilder as final). It's just preconfiguring an IRBuilder. Standard technique would be to return a unique_ptr<IRBuilder> instead.
However, subclassing is more pragmatic here. Other opinions?