search for: isidenticalto

On Jan 4, 2011, at 11:08 AM, Villmow, Micah wrote: > So, my question is, should isIdenticalTo take the memoperands into account? Is my patch correct? I almost feel like isIdenticalTo needs to be added to MachineMemOperand class. The MachineMemOperands are supposed to be used for optimizations only, your code should still be correct when stripping all memory operands. I think you would be...

I have ran across a case where the function isIdenticalTo is return true for instructions that are not equivalent. The instructions in question are load/store instructions, and is causing a problem with MachineBranchFolding. The problem is this, I have two branches of a switch statement that are identical, except for the size of the store. Here is some cu...

On Jan 4, 2011, at 11:08 AM, Villmow, Micah wrote: > I have ran across a case where the function isIdenticalTo is return true for instructions that are not equivalent. The instructions in question are load/store instructions, and is causing a problem with MachineBranchFolding. The problem is this, I have two branches of a switch statement that are identical, except for the size of the store. Here is some cu...

> -----Original Message----- > From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] > Sent: Tuesday, January 04, 2011 11:55 AM > To: Villmow, Micah > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Bug in MachineInstr::isIdenticalTo > > > On Jan 4, 2011, at 11:08 AM, Villmow, Micah wrote: > > > So, my question is, should isIdenticalTo take the memoperands into > account? Is my patch correct? I almost feel like isIdenticalTo needs to > be added to MachineMemOperand class. > > The MachineMemOpe...

...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, >...

...MCInst: op1 r0, r1, r2, op2, r3, r0, #c or MCInst: op1 op2 r0, r1, r2, r3, r0, #c What's Next? I am hoping to find some time to implement the followings in the near future: 1. Add BUNDLE opcode 2. MachineInstr class changes: new bit, changes to methods such as eraseFromParent(), isIdenticalTo(). 3. Change MachineInstr::iterator to skip over bundled MIs. Rename old iterator. 4. Add MachineInstr API to check for instruction properties and switch existing code over. 5. Add API to form a bundle. It would compute the proper def's and use's and add MachineOperands to the bundle MI....

...r3, r0, #c > or > MCInst: op1 op2 r0, r1, r2, r3, r0, #c > > What's Next? > > I am hoping to find some time to implement the followings in the near future: > 1. Add BUNDLE opcode > 2. MachineInstr class changes: new bit, changes to methods such as eraseFromParent(), isIdenticalTo(). > 3. Change MachineInstr::iterator to skip over bundled MIs. Rename old iterator. > 4. Add MachineInstr API to check for instruction properties and switch existing code over. > 5. Add API to form a bundle. It would compute the proper def's and use's and add MachineOperands to th...

...MCInst: op1 r0, r1, r2, op2, r3, r0, #c or MCInst: op1 op2 r0, r1, r2, r3, r0, #c What's Next? I am hoping to find some time to implement the followings in the near future: 1. Add BUNDLE opcode 2. MachineInstr class changes: new bit, changes to methods such as eraseFromParent(), isIdenticalTo(). 3. Change MachineInstr::iterator to skip over bundled MIs. Rename old iterator. 4. Add MachineInstr API to check for instruction properties and switch existing code over. 5. Add API to form a bundle. It would compute the proper def's and use's and add MachineOperands to the bundle MI....

...----- => MCInst: op1 r0, r1, r2, op2, r3, r0, #c or MCInst: op1 op2 r0, r1, r2, r3, r0, #c What's Next? I am hoping to find some time to implement the followings in the near future: 1. Add BUNDLE opcode 2. MachineInstr class changes: new bit, changes to methods such as eraseFromParent(), isIdenticalTo(). 3. Change MachineInstr::iterator to skip over bundled MIs. Rename old iterator. 4. Add MachineInstr API to check for instruction properties and switch existing code over. 5. Add API to form a bundle. It would compute the proper def's and use's and add MachineOperands to the bundle MI. 6....

...----- => MCInst: op1 r0, r1, r2, op2, r3, r0, #c or MCInst: op1 op2 r0, r1, r2, r3, r0, #c What's Next? I am hoping to find some time to implement the followings in the near future: 1. Add BUNDLE opcode 2. MachineInstr class changes: new bit, changes to methods such as eraseFromParent(), isIdenticalTo(). 3. Change MachineInstr::iterator to skip over bundled MIs. Rename old iterator. 4. Add MachineInstr API to check for instruction properties and switch existing code over. 5. Add API to form a bundle. It would compute the proper def's and use's and add MachineOperands to the bundle MI. 6....

On Tue, Oct 10, 2017 at 4:48 PM, Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 10/9/2017 3:10 AM, Gaël Jobin via llvm-dev wrote: > > Hi all, > > I got a silly bug when compiling our project with the latest Clang. Here's > the outputted assembly: > > tst r3, #255 > strbeq r6, [r7] > ldreq r6, [r4, r6, lsl #2] > strne r6, [r7, #4]