In rare situations involving AVX intrinsics, it seems LLVM can be coaxed into generating copies to arguments that look like this:
$xmm0 = VMOVAPSrr $xmm1, implicit-def $ymm0 CALL64 @something ymm0
This particular form of copy implicitly zeros the upper lanes of ymm0, hence there's an implicit-def for the register in the copy. The X86 implementation of describeLoadedValue doesn't attempt to describe this sort of copy (which is fine, it's rare and complicated), however that then causes the generic implementation in TargetInstrInfo::describeLoadedValue to fire an assertion saying it expected the target hook to handle it.
Gracefully degrade in this situation by not firing the assertion and just returning nullopt instead, indicating we can't currently describe the loaded value. An alternative would be to have the target hook recognise and reject this situation, IMHO it's cleaner to have the generic implementation just default to nullopt on unexpected inputs.
Note that I'm being slightly lazy by not uploading the source-input that creates this scenario, I can condense and upload that if needs be. As far as I understand it, this is a legitimate MIR instruction sequence though.