similar to: [LLVMdev] Tailcall optimization in jit stopped working

In X86CodeGen.cpp, the following code appears in the handler used for CALL64pcrel32 instructions: // Assume undefined functions may be outside the Small codespace. bool NeedStub = (Is64BitMode && (TM.getCodeModel() == CodeModel::Large || TM.getSubtarget<X86Subtarget>().isTargetDarwin())) || Opcode == X86::TAILJMPd;

On Jun 10, 2009, at 12:17 PM, Jeffrey Yasskin wrote: > In X86CodeGen.cpp, the following code appears in the handler used for > CALL64pcrel32 instructions: > > // Assume undefined functions may be outside the Small > codespace. > bool NeedStub = > (Is64BitMode && > (TM.getCodeModel() == CodeModel::Large || >

On Thu, Jun 11, 2009 at 12:54 PM, Evan Cheng<evan.cheng at apple.com> wrote: > > > > On Jun 10, 2009, at 12:17 PM, Jeffrey Yasskin wrote: > >> In X86CodeGen.cpp, the following code appears in the handler used for >> CALL64pcrel32 instructions: >> >>       // Assume undefined functions may be outside the Small codespace. >>       bool NeedStub =

The patch is against revision 42247. -------------- next part -------------- A non-text attachment was scrubbed... Name: tailcall-src.patch Type: application/octet-stream Size: 62639 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070923/4770302f/attachment.obj>

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

Hi Arnold, This is a very good first step! Thanks! Comments below. Evan Index: test/CodeGen/X86/constant-pool-remat-0.ll =================================================================== --- test/CodeGen/X86/constant-pool-remat-0.ll (revision 42247) +++ test/CodeGen/X86/constant-pool-remat-0.ll (working copy) @@ -1,8 +1,10 @@ ; RUN: llvm-as < %s | llc -march=x86-64 | grep LCPI | count 3 ;

Evan Cheng wrote: > I don't think so. Contribution welcome! :-) LLVM debugging support > isn't anywhere near where it needs to be. > Well, here's a rough sketch of what I was thinking of: class DebugInfoBuilder { public: /// Constructor DebugInfoBuilder(); /// Return the type defined by llvm.dbg.anchor.type StructType * GetAnchorType() const; ///

Are there any utility classes, similar to IRBuilder, for creating source level debugging info? -- Talin

I don't think so. Contribution welcome! :-) LLVM debugging support isn't anywhere near where it needs to be. Evan On May 20, 2008, at 9:53 PM, Talin wrote: > Are there any utility classes, similar to IRBuilder, for creating > source > level debugging info? > > -- Talin > > _______________________________________________ > LLVM Developers mailing list >

Hi Elena, On Thu, Mar 1, 2012 at 8:28 PM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote: > Even if you explicitly specify –stack-alignment=16 the aligned movs are > still generated. > > It is not an issue related to ABI. This looks like PR10841, explanation and the way to solve it: http://llvm.org/bugs/show_bug.cgi?id=10841 Cheers, -- Bruno Cardoso Lopes

I have installed samba4wins with samba 3.0.21 and I don?t know how to configure it (I tried what says the howto.txt but it didnt work). I wanted to know if someone has alredy used samba4wins and made it work. In that case please contact me, so I can ask you some questions. Thank you Gabriela

Even if you explicitly specify –stack-alignment=16 the aligned movs are still generated. It is not an issue related to ABI. See my original mail: ./llc -mattr=+avx -stack-alignment=16 < basic.ll | grep movaps | grep ymm | grep rbp vmovaps -176(%rbp), %ymm14 vmovaps -144(%rbp), %ymm11 vmovaps -240(%rbp), %ymm13 - Elena From: Cameron McInally

Here is a patch to improve argument lowering for tail calls. Before this patch all outgoing arguments were move to the stack slot where they would go on a normal function call and from there moved back to the tail call stack slot to prevent overwriting of values. After this patch only arguments that source from callers arguments (formal_arguments) are lowered this way. I moved some code

Hi there, it's me again. attached is preliminary support for tail calls on ppc 32. (once i get access to a 64bit machine that part will follow). It has passed the llvm-test with the -tailcallopt flag enabled. (after half a day on an old g4/800 :) okay to submit? probably not. :) suggestions. regards arnold -------------- next part -------------- A non-text attachment was scrubbed... Name:

Comments below. On Apr 15, 2008, at 4:24 AM, Nicolas Geoffray wrote: > 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. >

Sorry that also suffered from signature mismatch. So how about more like: typedef struct vtable_t { int (*pf4)(int a, int b, int c, int d); int (*pf5)(int a, int b, int c, int d, int e); } vtable_t; int f3(int (*pf5)(int a, int b, int c, int d, int e), int a, int b, int c, int d) { return pf5(a, b, c, d, d + d); } int f4(vtable_t *vt, int a, int b, int c, int d) { return vt->pf5(a, b,

typedef struct vtable_t { int (*pf4)(int a, int b, int c, int d); int (*pf5)(int a, int b, int c, int d, int e); } vtable_t; int f1(int (*pf4)(int a, int b, int c, int d)) { return pf4(1, 2, 3, 4); } int f2(vtable_t *vt) { return vt->pf4(1, 2, 3, 4); } gcc and clang will not tailcall these on arm with -O3. int f3(int (*pf5)(int a, int b, int c, int d, int e)) { return pf5(1, 2, 3,

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

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

Zachary, Thanks for the help on IRC earlier. I've got code that can capture a stack trace and then discover for each address, its module, function, source index, line, and column. I still have a couple of loose ends though. Do you know what's going on here? 1. There appears to be 8 bytes before every LineFragmentHeader. Here's some of my own debug output, which matches