similar to: [LLVMdev] Mapping bytecode to X86

On Fri, 23 Jun 2006, Fernando Magno Quintao Pereira wrote: > I am getting an error with my pass implementation, and I cannot figure > it out. Basically, I've implemented part of a register allocation > algorithm, but I am having problems to set the passes correctly. For > instance, for this program below, the following error message is > produced: It's hard to say

Dear LLVM guys, I am getting an error with my pass implementation, and I cannot figure it out. Basically, I've implemented part of a register allocation algorithm, but I am having problems to set the passes correctly. For instance, for this program below, the following error message is produced: .c ----------------------| .bc ---------------------------------

Dear LLVM guys, I've solved my problem with the passes, and compiled my first code using the new register allocator! Debugging was quite easy, using gdb. The problem was that I was forgetting to initialize the array that records the physical registers ever used (MachineFunction::UsedPhysRegs). This is a very minor thing, but I would suggest asserting that the vector has been initialized

On Mon, 26 Jun 2006, Fernando Magno Quintao Pereira wrote: > The problem is that, after the TwoAddressInstructionPass is used, the > code is no longer in SSA form, and my register allocator rely on > some SSA properties. I am using the Spiller in VirtRegMap.* to generate > the code, but the incorrect mapping still happens when I invoke the > setReg() method directly on machine

Thank you Chris. I will try to implement the TwoAddress pass to run on machine code. Why it has not been originally implemented to run on machine code? Is there anything that makes it troublesome after RA has been performed? Could you tell me if the transformations below are correct? 1) a := b op c --> a := b --> a := b a := a op c a

For the x86-64 target, I tried compiling a simple hello world. I don't understand the live interval information. Here's the machine instructions as dumped by LiveIntervalAnalysis: ********** MACHINEINSTRS ********** file hello.c line 3 b: 0 FNSTCW16m <fi#0>, 1, %NOREG, 0 FNSTCW16m <fi#0> 1 %mreg(0) 0 4 MOV8mi <fi#0>, 1, %NOREG, 1, 2 MOV8mi <fi#0> 1 %mreg(0) 1 2 8

I'm having an issue with the Stubs used by the JIT Compiler. I'm not sure if it's a bug or if I'm doing something incorrectly. I've got a long complicated function with the following basic blocks at the end of it (The complete .ll file is attached): falseBlock: ; preds = %__exp.exit340 ret int 617 codeRepl: ; preds = %__exp.exit340

I recently noticed a difference between the way GCC and LLVM treat sign extension for parameters and return values on x86-64. I could not find a clear answer in the x86-64 ABI [1] concerning whether parameters should be sign extended by the caller or callee and similarly whether return values should be sign extended by the caller or callee. Consider a simple 'signed char' division

In testing build patches for gcc 4.8 to allow darwin to have asan support, I ran across a defect in mach_override/mach_override.c... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289#c27 which was solved with the patch proposed by Alexander Potapenko in... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289#c29 Index: mach_override.c

Hi Micah, >>> assert(!isa<MemSDNode>(N)&& "Bad MemSDNode!"); >> >> you can't use getNode to allocate a MemSDNode because it does not >> allocate >> enough memory (MemSDNode has extra fields beyond the operands). >> > [Villmow, Micah] Duncan, thanks for the reply. But I don't see how I am generating a MemSDNode with this

On Wed, Feb 8, 2012 at 6:49 PM, Meador Inge <meadori at gmail.com> wrote: > I recently noticed a difference between the way GCC and LLVM treat > sign extension for parameters and return values on x86-64.  I could > not find a clear answer in the x86-64 ABI [1] concerning whether > parameters should be sign extended by the caller or callee and > similarly whether return values

--------- Forwarded Message --------- From： Tianhao Shen <17862703959 at 163.com> Date： 11/14/2018 09:31 To： craig.topper at gmail.com <craig.topper at gmail.com> Subject： Re: [llvm-dev] How to define an instruction Hi, Craig Thank you for replying to me. I guess that you misunderstand my meaning about "can'r run". I just want to run my instruction by LLVM using the

I am wondering about register allocation when there is a kill flag on the MachineOperand. Do I need to remove the kill flag? This code below is just an example from test\CodeGen\X86\xor.ll # Machine code for function test3: Frame Objects: fi#-2: size=4, align=4, fixed, at location [SP+8] fi#-1: size=4, align=8, fixed, at location [SP+4] Function Live Outs: %EAX BB#0: derived from LLVM BB

Thank you for answering my confusion. I have another questions. If I add really instructions instead intrinsics ,can I reach my purpose? I guess ,the answer is "can't". I don't find the anything about how machine to do about instructions,especially "ALU" instructions. Thank you again, Tianhao Shen On 11/14/2018 13:42，Craig Topper<craig.topper at gmail.com>

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 another computer I can test this on to see if

On Sep 1, 2010, at 11:14 AM, Dale Johannesen wrote: > > On Sep 1, 2010, at 6:25 AMPDT, Argyrios Kyrtzidis wrote: > >> The attached .ll files seem equivalent, but the resulting asm from >> 'opt-fail.ll' causes a crash to webkit. >> I suspect the usage of registers is wrong, can someone take a look ? > > Yes, the code here is wrong: > >> movl

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,

The following is the code fragment after "# *** IR Dump Before Prolog/Epilog Insertion & Frame Finalization ***:". * MOV32mi <fi#2>, 1, %reg0, 0, %reg0, 0 * * MOV32mr <fi#2>, 1, %reg0, 0, %reg0, %ECX<kill>* * %EAX<def> = MOV32rm <fi#2>, 1, %reg0, 0, %reg0* * MOV32mr %reg0, 1, %reg0, <ga:@one+4>, %reg0, %EAX<kill>* * %EAX<def> = MOV32rm

As you may have noticed, I have been working on a fast register allocator in the last week. The new allocator is intended to replace the local allocator for debug builds. Both allocators use a local allocation strategy. Each basic block is scanned from top to bottom, and virtual registers are assigned to physical registers as they appear. There are no live registers between blocks. Everything is

I sent a long message yesterday describing a problem I thought had to do with the JIT stubs. After further investigating, the problem seems to be in the code generation. The following basic block seems to have an error in it's code generation: __exp.exit: ; preds = %codeRepl258, %__exp_bb_bb.exit phi double [ 1.000000e+00, %codeRepl258 ], [ %.reload.reload.i,