diff options
author | Duncan P. N. Exon Smith <dexonsmith@apple.com> | 2016-09-11 17:12:28 +0000 |
---|---|---|
committer | Duncan P. N. Exon Smith <dexonsmith@apple.com> | 2016-09-11 17:12:28 +0000 |
commit | 3b22b181544ccb579411e2e5f537b4973c2f9a3c (patch) | |
tree | c0566be6f08aa1fe1ad659ba35b07b1a16cd66a9 /llvm/lib/CodeGen | |
parent | f887596ef87527fc8c07dab60a9305dc4b7aaf2f (diff) | |
download | bcm5719-llvm-3b22b181544ccb579411e2e5f537b4973c2f9a3c.tar.gz bcm5719-llvm-3b22b181544ccb579411e2e5f537b4973c2f9a3c.zip |
CodeGen: Assert that bundle iterators are valid
Add an assertion to the MachineInstrBundleIterator from instr_iterator
that the underlying iterator is valid. This is possible know that we
can check ilist_node::isSentinel (since r281168), and is consistent with
the constructors from MachineInstr* and MachineInstr&.
Avoiding the new assertion in operator== and operator!= requires four
(!!!!) new overloads each.
(As an aside, I'm strongly in favour of:
- making the conversion from instr_iterator explicit;
- making the conversion from pointer explicit;
- making the conversion from reference explicit; and
- removing all the extra overloads of operator== and operator!= except
const_instr_iterator.
I'm not signing up for that at this point, but being clear about when
something is an MachineInstr-iterator (possibly instr_end()) vs
MachineInstr-bundle-iterator (possibly end()) vs MachineInstr* (possibly
nullptr) vs MachineInstr& (known valid) would surely make code
cleaner... and it would remove a ton of boilerplate from
MachineInstrBundleIterator operators.)
llvm-svn: 281170
Diffstat (limited to 'llvm/lib/CodeGen')
0 files changed, 0 insertions, 0 deletions