[LLVMdev] VirtRegRewriter.cpp: LocalRewriter::ProcessUses()

Jakob Stoklund Olesen stoklund at 2pi.dk
Wed Oct 12 09:14:52 PDT 2011

On Oct 7, 2011, at 8:14 AM, Jonas Paulsson wrote:

> Hi,
> I think I've found a bug in this method.
> I ran it on an MI which already had two implicit-use operands, and which defined a register with a subregindex, ie reg::lo16.
> For the def-operand, with a subregindex, an implicit-use operand was added with this code:
> VirtUseOps.insert(VirtUseOps.begin(), MI.getNumOperands());
> MI.addOperand(MachineOperand::CreateReg(VirtReg,
>                                                false,  // isDef
>                                                true)); // isImplicit
> As, can be seen, it is presumed that this operand is always the last operand, this is however not the case. It in fact becomes the first of the impl-use operands.
> It might be preferred to change the addOperand(), so as to always insert the operand as the last element, or one could handle this locally by looking up the operand number, which unfortunately is not returned by addOperand(). 

Jonas, after looking into this, I am not sure I understand what you mean.

The VirtUseOps vector contains operand indexes.  For weird reasons, it has indexes of implicit operands first followed by explicit operand indexes at the end.

MI.addOperand() will always append an implicit register operand to the end of the instruction, so MI.getNumOperands() is the index of the added operand.

This index is added to the front of VirtUseOps because it corresponds to an implicit operand.

Are you saying that MI.addOperand() doesn't append the operand to the end? It really should.  

Also note that MI.addOperand() was mostly rewritten in r140744.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111012/32c57015/attachment.html>

More information about the llvm-dev mailing list