(Trivial) TargetPassConfig: assert when TargetMachine has no MCAsmInfo

[asb]

Summary

This is a pretty trivial, but I thought it was worth just checking that nobody feels it's completely the wrong thing to be doing.

The motivation is that when starting a new backend, you often start with a minimal stub, pretty much just FooTargetMachine and FooTargetInfo. Once that's built, you might naturally try llc -march=foo myinput.ll and it seems more developer-friendly if this ends up asserting due to the lack of MCAsmInfo with an informative message rather than just segfaulting.

[asb]

This patch got an LGTM from @bogner that for some strange reason wasn't registered by Phabricator even though the proper reply-to was used in the email.

[chandlerc]

Marking it as accepted in PHab as well.

Did you need someone to commit it?

llvm/trunk/lib/CodeGen/TargetPassConfig.cpp

void TargetPassConfig::addIRPasses() {
 
   if (getOptLevel() != CodeGenOpt::None && !DisablePartialLibcallInlining)
     addPass(createPartiallyInlineLibCallsPass());
 }
 
 /// Turn exception handling constructs into something the code generators can
 /// handle.
 void TargetPassConfig::addPassesToHandleExceptions() {
-  switch (TM->getMCAsmInfo()->getExceptionHandlingType()) {
+  const MCAsmInfo *MCAI = TM->getMCAsmInfo();
+  assert(MCAI && "No MCAsmInfo");
+  switch (MCAI->getExceptionHandlingType()) {
   case ExceptionHandling::SjLj:
     // SjLj piggy-backs on dwarf for this bit. The cleanups done apply to both
     // Dwarf EH prepare needs to be run after SjLj prepare. Otherwise,
     // catch info can get misplaced when a selector ends up more than one block
     // removed from the parent invoke(s). This could happen when a landing
     // pad is shared by multiple invokes and is also a target of a normal
     // edge from elsewhere.
     addPass(createSjLjEHPreparePass());