search for: getinstsizeinbytes

I'm noticing the X86InstrInfo::GetInstSizeInBytes() function returning incorrect sizes for some instructions. I looked through the llvm-dev archives and noticed that a patch was submitted once in April 2009 for instruction length calculation on amd-64. I'm using Intel Core 2 Duo (64 bit) so maybe there is a similar issue? I don't have a...

Hello, I'm trying to write some backends for LLVM that generate code that complies with SFI validation rules by re-implementing SFI for the LLVM x86 backend based on the Google NaCl project. However, in trying to implement 32-byte code alignment, X86InstrInfo::GetInstSizeInBytes() is returning incorrect instruction sizes for certain instructions (that I have seen so far): MOV32mi, LEA32r, MOV32mr, and MOV32rm. MOV32mi is always calculated incorrectly while the remaining 3 are sometimes calculated incorrectly. Just to illustrate: 8d 9c 24 30 0a 00 00...

...cause: 1. PPC instructions are of fixed length while X86 instructions are of variable length, and their length can change depending on features the target machine has. Not only that, but a relaxed X86 instruction will differ in size from its non-relaxed version. The function TrargetInstrInfo::getInstSizeInBytes is not, and can’t be, implemented for X86. It follows that: 2. Target addresses of branches cannot be computed before the code emission in X86. That’s why X86 relies on the layout process in MCAssembler, which occurs after the encoding is done and (amongst the rest) relaxes instructions that...

Hi Hal, A pre-emit pass will indeed be preferable. I originally thought of it, too, however I could not figure out how can such a pass have an access to information on instruction sizes and block alignments. I know that for X86, at least, the branch relaxation is happening during the layout phase in the Assembler, where I plan to integrate the nop insertion such that the new MCPerfNopFragment

...sume that all function calls must be made indirectly through the POT with the computation of the POT index and bin offset of the target function postponed until assembly printing. New machine module LTO pass to allocate functions into bins. This pass relies on targets implementing TargetInstrInfo::getInstSizeInBytes (MachineInstr) so that it knows (approximately) how large the final function code will be. Functions can also be packed in such a way that the number of inter-bin calls are minimized by taking the function call graph and/or execution profiles into account while packing. This pass only needs to run...

> > How about a default GetInstSize() as well? Return 1 for every > instruction except for some special TargetInstrInfo instructions, e.g. > PHI, IMPLICIT_DEF, LABEL. I don't know if it's useful or not. But > perhaps we can default most targets to it? > > I prefer not giving a default implementation and aborting with a message that says the target did not

Dear All, Is there a way in newer versions of LLVM (4.0 and higher) to find the size of an x86 instruction within a MachineFunctionPass?  If not, is there something I can do in the MC layer to do this? I'm trying to modify LLVM to implement something like Native Client in which groups of instructions are aligned at a specific alignment and have the same length.  My current approach is to

...directly through the POT >> with the computation of the POT index and bin offset of the target >> function postponed until assembly printing. >> >> New machine module LTO pass to allocate functions into bins. This pass >> relies on targets implementing TargetInstrInfo::getInstSizeInBytes >> (MachineInstr) so that it knows (approximately) how large the final >> function code will be. Functions can also be packed in such a way that >> the number of inter-bin calls are minimized by taking the function >> call graph and/or execution profiles into account while p...

...th the computation of the POT index and bin offset of the target > >>> function postponed until assembly printing. > >>> > >>> New machine module LTO pass to allocate functions into bins. This pass > >>> relies on targets implementing TargetInstrInfo::getInstSizeInBytes > >>> (MachineInstr) so that it knows (approximately) how large the final > >>> function code will be. Functions can also be packed in such a way that > >>> the number of inter-bin calls are minimized by taking the function > >>> call graph and/or exe...

...target >>> >>> function postponed until assembly printing. >>> >>> >>> >>> New machine module LTO pass to allocate functions into bins. This >>> >>> pass >>> >>> relies on targets implementing TargetInstrInfo::getInstSizeInBytes >>> >>> (MachineInstr) so that it knows (approximately) how large the final >>> >>> function code will be. Functions can also be packed in such a way >>> >>> that >>> >>> the number of inter-bin calls are minimized by taking th...

...tInstSize!"); > + return 0; > + } > + > + /// GetFunctionSize - Returns the size of the specified > MachineFunction. > + /// > + virtual unsigned GetFunctionSize(const MachineFunction &MF) const > = 0; > + > }; Great! But perhaps change the name to GetInstSizeInBytes() to be more explicit? Same for GetFunctionSize(). Hrm. Are there machines where instructions may not be byte sized? I guess we'll worry about it if someone adds that target. :-) > > > /// TargetInstrInfoImpl - This is the default implementation of > @@ -408,6 +420,7 @@ >...

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

I met with the Propeller team today (we work for the same company but it was my first time meeting two members on the team:) ). One thing I have been reassured: * There is no general disassembly work. General disassembly work would assuredly frighten off developers. (Inherently unreliable, memory usage heavy and difficult to deal with CFI, debug information, etc) Minimal amount of plumbing work