[PATCH] D21726: CodeGen: Use MachineInstr& in TargetInstrInfo, NFC

[Justin Bogner via llvm-commits]

"Duncan P. N. Exon Smith" <dexonsmith at apple.com> writes:
> dexonsmith created this revision.
> dexonsmith added reviewers: hfinkel, jfb, t.p.northover, bogner,
> kparzysz, tstellarAMD.
> dexonsmith added a subscriber: llvm-commits.
> Herald added subscribers: nemanjai, dsanders, jyknight, dschuff,
> arsenm, jfb, qcolombet, MatzeB, aemerson.
>
> This is mostly a mechanical change to make TargetInstrInfo API take
> MachineInstr& (instead of MachineInstr* or MachineBasicBlock::iterator)
> when the argument is expected to be a valid MachineInstr.  This is a
> general API improvement.
>
> Although it would be possible to do this one function at a time, that
> would demand a quadratic amount of churn since many of these functions
> call each other.  Instead I've done everything as a block and just
> updated what was necessary.
>
> This is mostly mechanical fixes: adding and removing `*` and `&`
> operators.  The only non-mechanical change is to split
> ARMBaseInstrInfo::getOperandLatencyImpl out from
> ARMBaseInstrInfo::getOperandLatency.  Previously, the latter took a
> `MachineInstr*` which it updated to the instruction bundle leader; now,
> the latter calls the former either with the same `MachineInstr&` or the
> bundle leader.
>
> As a side effect, this removes a bunch of MachineInstr* to 
> MachineBasicBlock::iterator implicit conversions, a necessary step
> toward fixing PR26753.
>
> Since this is such a monolithic change (and annoying to revert), I'd
> appreciate if a couple of others could confirm that the API changes in
> TargetInstrInfo.h are reasonable before I push this.

This looks great. Would you mind holding off on committing it until
tomorrow though? If you can I'd appreciate it.