search for: isframeindex

...;begin(); I != BB->end(); ) { [...] if (I->getOpcode() == FrameSetupOpcode || I->getOpcode() == FrameDestroyOpcode) { [...] } else { [...] for (unsigned i = 0, e = MI->getNumOperands(); i != e; ++i) if (MI->getOperand(i).isFrameIndex()) { // If this instruction has a FrameIndex operand, we need to use // that // target machine register info object to eliminate it. MRI.eliminateFrameIndex(MI, SPAdj, RS); // Revisit the instruction in full. Some instructions (e.g....

...%reg1025 = MOV32rm <fi#-1>, 1, %NOREG, 0 SV:1[??] %reg1026 = ADD32rm %reg1024, %reg1025, 1, %NOREG, 68 SV:1[q] %EAX = MOV32rr %reg1026 SV:0 RET SV:0 (For those following along, the SV:1[??] and SV:1[q] are the new parts here). For the [??], it looks like the IsFrameIndex isn't getting set for the first instruction there. A few quick comments on specific parts of the patch that I noticed so far: > + TargetSrcValue, I'm curious why you added a new node kind, TargetSrcValue, instead of just using the existing SRCVALUE. > + else if (MRO.SrcValue...

...your patch on x86 and it didn't appear to need any special changes. it might be needed to look at the addressing modes of a load/store to get the right offset. but i think it should work, if the lowering does not rewrite loads/stores into custom DAG nodes. > For the [??], it looks like the IsFrameIndex isn't getting set for the first > instruction there. yes, this needs to be added for each target. for our target i've modified the loadRegFromStackSlot and storeRegToStackSlot methods to add information on the frame index: BuildMI(MB, MBI, TII.get(STORE_REG_IMM)).addReg(framePointer)...

hi, i know it took a while, but here is a patch that adds a list of source values to machine instructions. i modified the DAGISelEmiter to automatically catch regular loads/stores. custom instructions and loads/stores rewritten by the lowering pass are not automatically captured. during the instruction selection a source value operand is added to the DAG for patterns matching a load/store.

...ing blocks you have, so that others > can benefit from your experience. Please send any info to the list, thanks! No major stumbling blocks during our backend porting, just minor changes. I'll list them anyways: 1) Some method names in MachineOperand were renamed to abbreviated names like isFrameIndex() -> isFI(). 2) const class llvm::MachineInstr has no member named clone() The call to could be replaced with MachineFunction::CloneMachineInstr(); 3) llvm::TargetInstrInfo::copyRegToReg() now returns 'bool' This used to be a void function. Easy to fix by just returning a boolean....

In the 2.3 release, we included a list of the major LLVM API changes. If you are working on upgrading your code from 2.3 to 2.4, I'd appreciate it if you could compile a list of the major stumbling blocks you have, so that others can benefit from your experience. Please send any info to the list, thanks! -Chris

hi, Florian Brandner wrote: > Dan Gohman wrote: >> On Wed, May 23, 2007 at 12:23:38AM -0700, Chris Lattner wrote: >>> Right. The original Value*'s are preserved in the DAG, but dropped when >>> MachineInstrs are created. We could add a machineoperand to capture this >>> Value* if desired. >> Another benefit of keeping the original Value*'s