[LLVMdev] VirtRegRewriter.cpp: LocalRewriter::ProcessUses()
Jonas Paulsson
jnspaulsson at hotmail.com
Fri Oct 7 08:14:18 PDT 2011
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().
< for (unsigned i = 0; i != MI.getNumOperands(); ++i) {
---
> for (unsigned i = 0, e = MI.getNumOperands(); i != e; ++i) {
1918c1918
< if (MO.isImplicit()){
---
> if (MO.isImplicit())
1923,1928d1922
< bool inserted=false;
< for(unsigned oi = 0;oi<VirtUseOps.size();oi++)
< if(VirtUseOps[oi]==i)
< inserted=true;
< if(inserted)
< continue; //skip: it was inserted by a partial def below
1930d1923
< }
1941,1951c1934,1937
< MachineOperand newMO = MachineOperand::CreateReg(VirtReg,
< false, // isDef
< true); // isImplicit
< MI.addOperand(newMO);
< int opNo; //FIX: the opNo should be returned by addOperand()
< for(unsigned oi=0;oi<MI.getNumOperands();oi++)
< if(MI.getOperand(oi).isIdenticalTo(newMO)){
< opNo=oi;
< break;
< }
< VirtUseOps.insert(VirtUseOps.begin(), opNo);
---
> VirtUseOps.insert(VirtUseOps.begin(), MI.getNumOperands());
> MI.addOperand(MachineOperand::CreateReg(VirtReg,
> false, // isDef
> true)); // isImplicit
/Jonas Paulsson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111007/f5fa0941/attachment.html>
More information about the llvm-dev
mailing list