search for: sizeofimm

...etX86RegNum(unsigned RegNo) const; > - bool isX86_64ExtendedReg(const MachineOperand &MO); > - unsigned determineREX(const MachineInstr &MI); > > bool gvNeedsLazyPtr(const GlobalValue *GV); > }; > @@ -405,139 +403,6 @@ > } > } > > -static unsigned sizeOfImm(const TargetInstrDesc *Desc) { > - switch (Desc->TSFlags & X86II::ImmMask) { > - case X86II::Imm8: return 1; > - case X86II::Imm16: return 2; > - case X86II::Imm32: return 4; > - case X86II::Imm64: return 8; > - default: assert(0 && "Immediate size n...

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And

...RM6m, (outs), (ins), "mfence", [(int_x86_sse2_mfence)]>, TB, Requires< [HasSSE2]>; In X86CodeEmitter.cpp in emitInstruction case X86II::MRM6m: case X86II::MRM7m: { intptr_t PCAdj = (CurOp+4 != NumOps) ? (MI.getOperand(CurOp+4).isImm() ? X86InstrInfo::sizeOfImm (Desc) : 4) : 0; ... If I'm reading the code correctly, the NumOps is 0 and CurOp is 0 so we to get the 4th operand from the MFENCE operation which has no operands so we get an error. I'm not sure what this code is trying to do. Should the condition be < NumOps? Thanks,...

..."mfence", [(int_x86_sse2_mfence)]>, TB, Requires< > [HasSSE2]>; > > In X86CodeEmitter.cpp in emitInstruction > > case X86II::MRM6m: case X86II::MRM7m: { > intptr_t PCAdj = (CurOp+4 != NumOps) ? > (MI.getOperand(CurOp+4).isImm() ? X86InstrInfo::sizeOfImm > (Desc) : 4) : 0; > ... > > If I'm reading the code correctly, the NumOps is 0 and CurOp is 0 so > we to get the 4th operand from the MFENCE operation which has no > operands so we get an error. I'm not sure what this code is trying to > do. Should the condition b...

..., [(int_x86_sse2_mfence)]>, TB, Requires< >> [HasSSE2]>; >> >> In X86CodeEmitter.cpp in emitInstruction >> >> case X86II::MRM6m: case X86II::MRM7m: { >> intptr_t PCAdj = (CurOp+4 != NumOps) ? >> (MI.getOperand(CurOp+4).isImm() ? X86InstrInfo::sizeOfImm >> (Desc) : 4) : 0; >> ... >> >> If I'm reading the code correctly, the NumOps is 0 and CurOp is 0 so >> we to get the 4th operand from the MFENCE operation which has no >> operands so we get an error. I'm not sure what this code is trying >> t...

...owf")] = currentModule()->getFunction("powf"); func = CloneFunction(originalFunc, val); currentModule()->getFunctionList().push_back(func); unfortunately after this we get an assert: vp-tris: /home/zack/projects/general/llvm/lib/Target/X86/X86CodeEmitter.cpp:412: unsigned int sizeOfImm(const llvm::TargetInstrDesc*): Assertion `0 && "Immediate size not set!"' failed. which I'm a little confused about. Any idea what might be causing this and how to fix it? z

...any clue why the new PointerIntPair implementation might fail. It doesn't seem very safe to me to store other data into a pointer to begin with, but surely the lower bits must be a safer location than the upper bits? The actual crash I'm seeing is preceded by an assert in X86InstrInfo::sizeOfImm: "Immediate size not set!". Tracing backward, I'm seeing a MachineInstr with opcode MOV32rm and NumOperands equal to 6 (which is 5 in earlier revisions). I'm not sure if this actually helps explain the bug but it's one of the weird things that happen with revision 67979 and su...

...terIntPair > implementation might fail. It doesn’t seem very safe to me to store > other data into a pointer to begin with, but surely the lower bits > must be a safer location than the upper bits? > > The actual crash I’m seeing is preceded by an assert in > X86InstrInfo::sizeOfImm: "Immediate size not set!". Tracing > backward, I’m seeing a MachineInstr with opcode MOV32rm and > NumOperands equal to 6 (which is 5 in earlier revisions). I’m not > sure if this actually helps explain the bug but it’s one of the > weird things that happen with revis...

...r this is actually the cause or if something's wrong with the Module coming into InstCombine, but given that you're seeing a similar problem elsewhere, it's not unlikely that this is the real cause. > The actual crash I’m seeing is preceded by an assert in > X86InstrInfo::sizeOfImm: "Immediate size not set!". Tracing > backward, I’m seeing a MachineInstr with opcode MOV32rm and > NumOperands equal to 6 (which is 5 in earlier revisions). I’m not > sure if this actually helps explain the bug but it’s one of the > weird things that happen with revis...

...plementation might fail. It doesn’t seem very safe >> to me to store other data into a pointer to begin with, but surely >> the lower bits must be a safer location than the upper bits? >> >> The actual crash I’m seeing is preceded by an assert in >> X86InstrInfo::sizeOfImm: "Immediate size not set!". Tracing >> backward, I’m seeing a MachineInstr with opcode MOV32rm and >> NumOperands equal to 6 (which is 5 in earlier revisions). I’m not >> sure if this actually helps explain the bug but it’s one of the >> weird things that h...