This is an archive of the discontinued LLVM Phabricator instance.

CodeGen: Use mop_iterator instead of MIOperands/ConstMIOperands
ClosedPublic

Authored by MatzeB on May 21 2015, 9:16 PM.

Details

Summary

MIOperands/ConstMIOperands are classes iterating over the MachineOperand
of a MachineInstr, however MachineInstr::mop_iterator does the same
thing.

I assume these two iterators exist to have a uniform interface to
iterate over the operands of a machine instruction bundle and a single
machine instruction. However in practice I find it more confusing to have 2
different iterator classes, so this patch transforms (nearly all) MIOperands
users to mop_iterators.

The only exception being MIOperands::anlayzePhysReg() and
MIOperands::analyzeVirtReg() which have no equivalent, I leave that
as an exercise for the next patch.

Diff Detail

Repository
rL LLVM

Event Timeline

MatzeB updated this revision to Diff 26305.May 21 2015, 9:16 PM
MatzeB retitled this revision from to CodeGen: Use mop_iterator instead of MIOperands/ConstMIOperands.
MatzeB updated this object.
MatzeB edited the test plan for this revision. (Show Details)
MatzeB added reviewers: atrick, qcolombet.
MatzeB set the repository for this revision to rL LLVM.
MatzeB added a subscriber: Unknown Object (MLST).
qcolombet edited edge metadata.May 22 2015, 10:47 AM

Hi Matthias,

Although both iterators have the same capabilities, I found it convenient to use one or another depending on the context.
That being said, I do not feel strongly about deprecating one, if Andy agrees.

Anyhow, some of the for range based loops looks good, the other ones not such much (that's why I am a bit reluctant for the whole change).

Cheers,
-Quentin

lib/CodeGen/EarlyIfConversion.cpp
229

While you are here, maybe we can use a reference for this one.

atrick accepted this revision.May 27 2015, 9:39 PM
atrick edited edge metadata.

I think this is a call that you and Quentin can make. No objections here.

Range based for loops largely obviate the need for another abstraction. It is still convenient to have the operand number, but I won't argue for that.

I wonder if part of the reason for unifying iterators was to gradually migrate passes to operate on bundles. I personally don't think we should support bundles before register coalescing though unless there is a very compelling reason.

It seems that we should also move analyzePhys/VirtReg out of the iterator base class. I don't think calling it on an iterator is a very good API anyway.

This revision is now accepted and ready to land.May 27 2015, 9:39 PM
MatzeB closed this revision.May 29 2015, 2:36 PM

This landed in r238539 (apparently "Differential Revision: XXX" is only picked up if it is the last line of the commit messages).