[NFC]Add assert to avoid possibly deref nullptr

[XinWang10]

These 2 functions could be called by AsmPrinter::doInitialization in AsmPrinter.cpp. doInitialization init MMI in the beginningMMI = MMIWP ? &MMIWP->getMMI() : nullptr;, MMI has the possibility to be nullptr, which could make the later deref crash. I think in most time MMI could not be nullptr, but from the view of function implementation, it could be, so I'd like to add assert to it, if this could be a problem, then we could avoid crash.

[phoebewang]

LGTM.

[KanRobert]

LGTM

[adrian-prantl]

@XinWang10 This patch doesn't fix the issue that you discovered. Most vendors ship LLVM with assertions disable for performance reasons. Can you fix this properly by either making the code that depends on MMI conditional or by making it impossible to have a null MMI member in AsmPrinter?

[JDevlieghere]

+1 to what Adrian said. This commit doesn't improve anything: it just changes the type of crash from a segmentation fault to an abort, if you have asserts enabled. If the internal-consistency guarantee is that MMI is never null because MMIWP is never null, then you should assert that. But looking at the code (auto *MMIWP = getAnalysisIfAvailable<MachineModuleInfoWrapperPass>();) it very much looks intentional. So it looks like these asserts are enforcing something that's not guaranteed. I think this should be reverted.

[adrian-prantl]

As a general rule of thumb, assert() and llvm_unreachable() should only be used on code paths that are (at the time of writing) actually impossible to reach. They are not a replacement for error handling.

[XinWang10]

@JDevlieghere @adrian-prantl I know your principle is right. The reason I changed in this way is that this code has existed for several years, we haven't found any crash here so far, so I think add an assert would be a light weight fix to it. Using if-condition must be correct, but considering I have no evidence MMI would be nullptr from author's intention and if-condition could take more resource, I made this decision. I think we could let it here and if it do have risk it's not too late to change it back.
If you guys strongly object this patch, I would revert it and use if-condition instead.

[JDevlieghere]

First off, I appreciate you trying to fix this issue.

I think add an assert would be a light weight fix to it.

As Adrian and I pointed out earlier, the current patch doesn't fix anything. I would go even further and say it makes things worse, because the assert states that MMI cannot be null, while there's a code patch that shows that it can be.

I have no evidence MMI would be nullptr from author's intention

You pointed out that it can be null if MMIWP is null, which is the case if the analysis pass is not found. If you look at the implementation of findAnalysisPass, it has a comment saying:

/// Find the pass that implements Analysis AID. Search immutable
/// passes and all pass managers. If desired pass is not found
/// then return NULL.

Clearly, it's possible for a pass to not exist. If someone were to build LLVM without MachineModuleInfoWrapperPass, MMIWP would be NULL and consequently MMI would be NULL.

If you guys strongly object this patch, I would revert it and use if-condition instead.

Yes, we should use an if-condition instead.

[dwblaikie]

(doesn't seem to be debug info related)

+1 to @aprantl and @JDevlieghere - if the null deref was reachable, then this needs proper error handling, the assert is insufficient/not the right tool. (& this needs a test case, if it is reachable)