similar to: [LLVMdev] Destination of callee saved register

Hello list, i am currently trying to implement tail call optimization in the X86 backend , so far i have it working for cases (modulo many unknown bugs :) where the tail called function is a destination within the source file and frame pointer elimination is performed. i implemented it as a dagcombiner transformation running in post legalized phase within the

Sent from my iPhone On Aug 8, 2007, at 10:46 AM, Arnold Schwaighofer <arnold.schwaighofer at gmail.com > wrote: > Hi Anton and Dale > first thanks for your answers. > > On 8 Aug 2007, at 16:43, Anton Korobeynikov wrote: > >> Hello, Arnold. >> >>> Is there a way to indicate that the register the tail call >>> instruction uses as destination

Hi Anton and Dale first thanks for your answers. On 8 Aug 2007, at 16:43, Anton Korobeynikov wrote: > Hello, Arnold. > >> Is there a way to indicate that the register the tail call >> instruction uses as destination needs to be valid after the callee >> saved registers have been restored? (some X86InstrInfo.td foo magic >> maybe ?) > It's wrong way to do the

I want to generate the instruction like addi 40, r3 ! i.e. r3 = r3 + 40 The format i wrote is def ADDI : F1<opcode, (outs IntRegs:$dst), (ins IntRegs:$dst, i32imm:$imm) "addi $imm, $dst", [(set $IntRegs:$dst, (add $IntRegs:$dst, i32imm:$c))] but it is not compiling. what should be the format. vikram -- View this message

Hello, Arnold. > Is there a way to indicate that the register the tail call > instruction uses as destination needs to be valid after the callee > saved registers have been restored? (some X86InstrInfo.td foo magic > maybe ?) It's wrong way to do the things. Because in this case you either violate the ABI for callee, or you're restricted to do tail call lowering only for

Hello, Arnold. > with the sentence i tried to express the question whether there is a > way to persuade the code generator to use another register to load (or > move) the function pointer to (right before the callee saved register > restore) but thinking a little further that's nonsense. Why don't define some special op for callee address and custom lower it? I really

Hello, find enclosed a first patch for adding tail call optimizations for thumb1 targets. I assume that this list is the right place for publishing patches for review? Since this is my first proposal for LLVM, I'd very much appreciate your feedback. What the patch is meant to do: For Tail calls identified during DAG generation, the target address will be loaded into a register by use

Hi, Have you try to directly describe such patterns in tblgen file? Like this: (brcond (i32 (cond_op RC:$rs, RC:$rt)), bb:$offset) MIPS backend does that. I also do this in my own backend, and seem to be working fine. On Mon, Jan 7, 2013 at 11:55 AM, Vikram Singh <vsp1729 at gmail.com> wrote: > I have seen that most of the targets do comparison and branching > in two separate

There is format in sparc <pre> subcc %r1, %r2, %r3 bne .label </pre> I want instruction like this <pre> bne %r1, %r2, .label </pre> </BR> I am referring to sparc code for this implementation (llvm-3.1).</BR></BR> 1. Should I change the SPBranch and BCOND structs in .td file.</BR> 2. Should I change BuildMI constructs in

Hi Borja, On Jul 10, 2012, at 6:26 PM, Borja Ferrer wrote: > Hello, > > I would like to know if there's a way of setting the callee-saved register list inside getCalleeSavedRegs() to make the PEI pass save/restore only one half of a register pair if the other half is not being used, instead of saving the whole pair. Here is an example of what I try to explain to make things more

Hi Abhinash, On 10/06/13 23:05, Abhinash Jain wrote: > How to get memory address of all operands which constitutes an expression ? in LLVM IR, the operands of most expression are registers, so don't have a memory address. In short, you can't always succeed. However in cases where the operands do come from memory in a fairly direct way, you can find out what the memory is using the

Vladimir Prus wrote: > I've another problem. There's one register, gr6, which is used to return > high part of return value for functions returning 64-bit values. For such > functions, the register should not be saved, naturally. > > But when function does not return 64-bit value, then the register must be > saved. How can I express this in .td file? Ok, I've managed

I have seen that most of the targets do comparison and branching in two separate instructions e.g. 'cmpl' followed by 'br' in x86 or the like. LLVM IR is also in same manner. I want to implement comparison+branching in one instruction like beq r1, r2, .label #if r1==r2 then jump to .label How to merge two instruction into one. Regards Vikram Singh -- View this

Hello, I would like to know if there's a way of setting the callee-saved register list inside getCalleeSavedRegs() to make the PEI pass save/restore only one half of a register pair if the other half is not being used, instead of saving the whole pair. Here is an example of what I try to explain to make things more clear: Suppose this situation where we have a register file of 8bit regs, and

Hi Nikos, You can model your requirement in the *.td using RegisterClass as def SrcRegs : RegisterClass<"Src", [i32], 4, (add R0, R2, R4, R6 )>; def DstRegs : RegisterClass<"Dst", [i32], 4, (add R1, R3, R5, R7 )>; Thanks ~Umesh On Thu, Nov 7, 2013 at 8:25 PM, Stavropoulos Nikos < n.stavropoulos at think-silicon.com> wrote: > Hi all.

On Fri, May 13, 2016 at 3:45 PM, Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Sanjay, > > > > On May 13, 2016, at 3:32 PM, Sanjoy Das <sanjoy at playingwithpointers.com> > wrote: > > > > Hi, > > > > This is a proposal to introduce a mechanism to LLVM that uses runtime > > instrumentation to verify that a call

How to get memory address of all operands which constitutes an expression ? eg. a=b+c; (want to know the memory address of b and c)...... Since I want this at run time, So at assembly level this expression will become something like as follows:- Load r1, M[b] Load r2, M[c] r3=r1+r2 store M[a],r3 Now what i want to do is that, at every store instruction, I should get the memory address of all

I’ve seen this done in the past without compiler support (for the case of handwritten or JIT’d, etc functions that need checking). It worked something like this: 1. Pass calls to the risky functions through a macro/template or such. 2. In release mode, this turns into a no-op. In debug mode, this sends the calls through a handwritten asm wrapper that sets all the callee-save registers to random

Hi, Jiong, Thanks for the patch! It is a great start to support 32bit register in BPF. In the past, I have studied a little bit to see whether 32bit register support may reduce the number of unnecessary shifts on x86_64 and improve the performance. Looking through a few bpf programs and it looks like the opportunity is not great, but still nice to have if we have this capability. As you

----- Original Message ----- > From: "Francois Pichet" <pichet2000 at gmail.com> > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, November 18, 2013 2:26:30 PM > Subject: [LLVMdev] Unaligned load/store for callee-saved 128-bit registers > > > > On my (out-of-tree) target I have 16 128-bit registers. >