diff options
| author | Vedant Kumar <vsk@apple.com> | 2020-02-27 09:58:24 -0800 |
|---|---|---|
| committer | Vedant Kumar <vsk@apple.com> | 2020-02-28 14:30:40 -0800 |
| commit | 0368b42295325dc3b3e7deaa72a2db9e2b049df2 (patch) | |
| tree | 5fc68afbff1fbf7daa720fe37ae3bcf929e0c3e7 /llvm/lib/ProfileData/Coverage/CoverageMappingWriter.cpp | |
| parent | 52f889abecc71cac2defd18a5fbba10880030867 (diff) | |
| download | llvm-0368b42295325dc3b3e7deaa72a2db9e2b049df2.zip llvm-0368b42295325dc3b3e7deaa72a2db9e2b049df2.tar.gz llvm-0368b42295325dc3b3e7deaa72a2db9e2b049df2.tar.bz2 | |
[entry values] ARM: Add a describeLoadedValue override (PR45025)
As a narrow stopgap for the assertion failure described in PR45025, add
a describeLoadedValue override to ARMBaseInstrInfo and use it to detect
copies in which the forwarding reg is a super/sub reg of the copy
destination. For the moment this is unsupported.
Several follow ups are possible:
1) Handle VORRq. At the moment, we do not, because isCopyInstrImpl
returns early when !MI.isMoveReg().
2) In the case where forwarding reg is a super-reg of the copy
destination, we should be able to describe the forwarding reg as a
subreg within the copy destination. I'm not 100% sure about this, but
it looks like that's what's done in AArch64InstrInfo.
3) In the case where the forwarding reg is a sub-reg of the copy
destination, maybe we could describe the forwarding reg using the
copy destinaion and a DW_OP_LLVM_fragment (I guess this should be
possible after D75036).
https://bugs.llvm.org/show_bug.cgi?id=45025
rdar://59772698
Differential Revision: https://reviews.llvm.org/D75273
Diffstat (limited to 'llvm/lib/ProfileData/Coverage/CoverageMappingWriter.cpp')
0 files changed, 0 insertions, 0 deletions