search for: imm64

Copy Ii32 in X86InstrFormats.td rename to Ii64 and change Imm32 to Imm64. Instantiate your instruction inheriting from Ii64. Pass RawFrm to the form parameter. Initial documentation for the encoding system is attached. ~Craig On Wed, Mar 28, 2018 at 4:50 PM, Gus Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I am attempting to create an instructi...

I am attempting to create an instruction which takes a single 64-bit immediate. This doesn't seem like a thing that would exist already (because who needs an instruction which just takes an immediate?) How might I implement this easily? Perhaps I could use a format which encodes a register, which is then unused? Thanks for the help. Gus -------------- next part -------------- An HTML

...pt to decode the "garbage" in the instruction stream, even if there is a jump over it? (IIRC they will decode ahead of the PC and hiccup (but not fault) on garbage). Maybe it would be better to steganographically encode the value inside the instruction stream? On x86 you could use 48b8<imm64> which only has 2 bytes overhead for an i64 (putting a move like that, which moves into a caller-saved register on entry, would effectively be a noop). This is some pretty gnarly target-dependent stuff which seems like it would best be hidden in the backend (e.g. architectures that have "co...

...ot;garbage" in > the instruction stream, even if there is a jump over it? (IIRC they will > decode ahead of the PC and hiccup (but not fault) on garbage). Maybe it > would be better to steganographically encode the value inside the > instruction stream? On x86 you could use 48b8<imm64> which only has 2 bytes > overhead for an i64 (putting a move like that, which moves into a > caller-saved register on entry, would effectively be a noop). On the contrary, I think this is a good argument for allowing (not forcing) frontends to encode the prefix data as they please, thus...

...gt;> >> >> On Thu, Feb 18, 2016 at 5:59 PM, Tamazov, Artem <Artem.Tamazov at amd.com<mailto:Artem.Tamazov at amd.com>> wrote: >> >> Hmm... I would check if 64-bit immediate operands are allowed in the x86 ISA. >> >> >> >> "MOV r64, imm64" is allowed in 3-528 Vol 2A of Intel manual, so yes it is legal >> >> >> >>> >>> Also I would play with -mcpu option. >> >> >> >> What do you mean? like "-mcpu=x86_64" ? >> >> Thanks, >> >> >> &...

Hi, I would like to propose that we introduce a mechanism in IR to allow arbitrary data to be stashed before a function body. The purpose of this would be to allow additional data about a function to be looked up via a function pointer. Two use cases come to mind: 1) We'd like to be able to use UBSan to check that the type of the function pointer of an indirect function call matches the

...> > the instruction stream, even if there is a jump over it? (IIRC they will > > decode ahead of the PC and hiccup (but not fault) on garbage). Maybe it > > would be better to steganographically encode the value inside the > > instruction stream? On x86 you could use 48b8<imm64> which only has 2 > bytes > > overhead for an i64 (putting a move like that, which moves into a > > caller-saved register on entry, would effectively be a noop). > > On the contrary, I think this is a good argument for allowing > (not forcing) frontends to encode the pref...

...t; @@ -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 not set!"); > - return 0; > - } > -} > - > -/// isX86_64ExtendedReg - Is the MachineOperand a x86-64 extended > register? > -/// e.g. r8, xmm8, etc. > -bool Emitter::isX86_64ExtendedReg(const Ma...

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