search for: emitmemmodrmbyte

Displaying 14 results from an estimated 14 matches for "emitmemmodrmbyte".

2009 Apr 08
1
[LLVMdev] [PATH] Fix instruction size computation on amd64
Hi, The attached small path fixes X86InstrInfo::getMemModRMByteSize to be consistent with the emit code in X86CodeEmitter::emitMemModRMByte on amd64. Zoltan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090408/ad831982/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm.diff...
2006 Sep 14
1
[LLVMdev] Hello World crashes!
...; RegOpcode < 8 && RM < 8 && "ModRM Fields out of range!"' failed. lli((anonymous namespace)::PrintStackTrace()+0x15)[0x84ab499] /lib/tls/libc.so.6[0x3d7ec8] /lib/tls/libc.so.6(abort+0x15)[0x3d94f5] /lib/tls/libc.so.6[0x3d1619] lli((anonymous namespace)::Emitter::emitMemModRMByte(llvm::MachineInstr const&, unsigned int, unsigned int)+0x219)[0x81af7c9] Aborted Thanks, Arthur. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060914/1b609019/attachment.html>
2006 Jul 14
2
[LLVMdev] Hello World crashes!
...; RegOpcode < 8 && RM < 8 && "ModRM Fields out of range!"' failed. lli((anonymous namespace)::PrintStackTrace()+0x15)[0x84ab499] /lib/tls/libc.so.6[0x3d7ec8] /lib/tls/libc.so.6(abort+0x15)[0x3d94f5] /lib/tls/libc.so.6[0x3d1619] lli((anonymous namespace)::Emitter::emitMemModRMByte(llvm::MachineInstr const&, unsigned int, unsigned int)+0x219)[0x81af7c9] Aborted
2013 Dec 12
3
[LLVMdev] [RFC PATCH 1/2] x86: Fix ModR/M byte output in 16-bit addressing mode
.... diff --git a/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp b/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp index 7952607..12a30cf 100644 --- a/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp +++ b/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp @@ -402,6 +402,56 @@ void X86MCCodeEmitter::EmitMemModRMByte(const MCInst &MI, unsigned Op, unsigned BaseRegNo = BaseReg ? GetX86RegNum(Base) : -1U; + // 16-bit addressing forms of the ModR/M byte have a different encoding for + // the R/M field and are far more limited in which registers can be used. + if (Is16BitMemOperand(MI, Op)) { + if...
2013 Dec 16
0
[LLVMdev] [RFC PATCH 1/2] x86: Fix ModR/M byte output in 16-bit addressing mode
...t/X86/MCTargetDesc/X86MCCodeEmitter.cpp > b/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp > index 7952607..12a30cf 100644 > --- a/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp > +++ b/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp > @@ -402,6 +402,56 @@ void X86MCCodeEmitter::EmitMemModRMByte(const MCInst > &MI, unsigned Op, > > unsigned BaseRegNo = BaseReg ? GetX86RegNum(Base) : -1U; > > + // 16-bit addressing forms of the ModR/M byte have a different encoding > for > + // the R/M field and are far more limited in which registers can be > used. > +...
2004 Sep 01
2
[LLVMdev] Problem with CVS LLVM build in obj != src dir case
...lvm/obj/tools/llvmc' 2) gcc 3.5 (mainline CVS) Mostly result using ~0 (signed int) expression as value of unsigned int function parameter. Compiling X86CodeEmitter.cpp /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86CodeEmitter.cpp: In member function `void<unnamed>::Emitter::emitMemModRMByte(const llvm::MachineInstr&, unsigned int, unsigned int)': /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86CodeEmitter.cpp:437: warning: converting of negative value `-0x000000001' to `unsigned int' /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86CodeEmitter.cpp:43...
2008 Apr 04
0
[LLVMdev] Being able to know the jitted code-size before emitting
...'s either only one single byte for opcode or one additional ModR/M byte. Again, all the information is right there. 3. Some memory instructions needs a SIB byte. 4. Process the operands! Some special handling for operands that made up of the memory address. But the logic is all there in emitMemModRMByte. What do you think? Evan > > >> >> Suppose you have the size, can't you pass the desired buffer size to >> MachineCodeEmitter and have it do the right thing? > > Sure, that's what I'm doing. The emitter with the SizeEmitter class > will > give th...
2008 Apr 05
2
[LLVMdev] Being able to know the jitted code-size before emitting
...single byte for opcode or one additional ModR/M byte. Again, > all the information is right there. > 3. Some memory instructions needs a SIB byte. > 4. Process the operands! Some special handling for operands that made > up of the memory address. But the logic is all there in > emitMemModRMByte. > > What do you think? > > That's doable, but I'm afraid I'll have to duplicate many code (eg emitMemModRMByte -> sizeMemModRMByte and probably others). That's not a problem (I'm thinking bug fixes and improvements, we'll have to handle two duplicated...
2008 Apr 16
0
[LLVMdev] Being able to know the jitted code-size before emitting
...= 2; > if (CurOp != NumOps) > - emitConstant(MI.getOperand(CurOp++).getImm(), sizeOfImm(Desc)); > + emitConstant(MI.getOperand(CurOp++).getImm(), > X86InstrInfo::sizeOfImm(Desc)); > break; > } > case X86II::MRMDestMem: { > @@ -706,7 +571,7 @@ > emitMemModRMByte(MI, CurOp, getX86RegNum(MI.getOperand(CurOp > +4).getReg())); > CurOp += 5; > if (CurOp != NumOps) > - emitConstant(MI.getOperand(CurOp++).getImm(), sizeOfImm(Desc)); > + emitConstant(MI.getOperand(CurOp++).getImm(), > X86InstrInfo::sizeOfImm(Desc)); >...
2004 Sep 02
0
[LLVMdev] Problem with CVS LLVM build in obj != src dir case
...wanderer/pkg/build/llvm/src/llvm/include/llvm/PassSupport.h:171: warning: converting of negative value `-0x000000001' to `unsigned int' Compiling X86CodeEmitter.cpp /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86CodeEmitter.cpp: In member function `void<unnamed>::Emitter::emitMemModRMByte(const llvm::MachineInstr&, unsigned int, unsigned int)': /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86CodeEmitter.cpp:437: warning: converting of negative value `-0x000000001' to `unsigned int' /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86CodeEmitter.cpp:43...
2008 Apr 15
4
[LLVMdev] Being able to know the jitted code-size before emitting
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
2008 Apr 04
3
[LLVMdev] Being able to know the jitted code-size before emitting
Evan Cheng wrote: > On Apr 1, 2008, at 12:50 AM, Nicolas Geoffray wrote: > > > That's a hack. :-) It is if you think that code emitter should only be used for actually writing somewhere the data. It is not if you find it another useful utility ;-) > Some targets already have ways to compute the exact > size of a function. See ARM::GetFunctionSize()
2004 Sep 02
1
[LLVMdev] Problem with CVS LLVM build in obj != src dir case
...rc/llvm/include/llvm/PassSupport.h:171: > warning: converting of negative value `-0x000000001' to `unsigned int' > > Compiling X86CodeEmitter.cpp > /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86CodeEmitter.cpp: In > member function `void<unnamed>::Emitter::emitMemModRMByte(const > llvm::MachineInstr&, unsigned int, unsigned int)': > /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86CodeEmitter.cpp:437: > warning: converting of negative value `-0x000000001' to `unsigned int' > /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X...
2008 Apr 05
0
[LLVMdev] Being able to know the jitted code-size before emitting
...r opcode or one additional ModR/M byte. Again, >> all the information is right there. >> 3. Some memory instructions needs a SIB byte. >> 4. Process the operands! Some special handling for operands that made >> up of the memory address. But the logic is all there in >> emitMemModRMByte. >> >> What do you think? >> >> > > That's doable, but I'm afraid I'll have to duplicate many code (eg > emitMemModRMByte -> sizeMemModRMByte and probably others). That's > not a > problem (I'm thinking bug fixes and improvements, we...