search for: i_cal

...itly assuming that > the call was marked "tail call" by the LLVM optimizers. So you also need to check > under what conditions the LLVM optimizers do that. The backend does not check the following condition but assumes it to be true. >From <http://llvm.org/docs/LangRef.html#i_call>: The optional "tail" marker indicates whether the callee function accesses any allocas or varargs in the caller. If the "tail" marker is present, the function call is eligible for tail call optimization. Note that calls may be marked "tail" even if they do not oc...

"float (i32)* (float (i32)*)*" is not a return type. According to the description of the 'call' instruction in LLVM Assembly Language Reference Manual (http://llvm.org/docs/LangRef.html#i_call) this is a signature of the pointer to function value being invoked (which includes the return type). In your case the full signature is printed because get_ptr returns a pointer to function (read item 5 in the Arguments section of the 'call' Instruction section). Victor On 12 April 201...

Hi Jon, > >From what I have understood of the LLVM docs about when tail calls get > eliminated on x86 and x64 it should be a tail call, yes. > > http://llvm.org/docs/CodeGenerator.html#tailcallopt > > . Caller and callee have the calling convention fastcc. > . The call is a tail call - in tail position (ret immediately follows call and > ret uses value of call or

...ng me for two reasons: > > 1) I am not sure why it is a tail call (i.e. it does not look like it is in the tail position) The "tail" marker has a very specific description in LLVM IR: it says that the caller does not access the callee's stack: http://llvm.org/docs/LangRef.html#i_call > 2) When I instrument the code using my opt pass, none of the instrumentation functions in the callee get called, leading me to believe that some funny business is going on. I don't know about this. -Chris > > Below I have pasted the tail call in question and surrounding code....

I'm sorry that I should remove the comment. In fact my question is about the "float (i32)* (float (i32)*)*", why we use this kind of return type instead of just "float (i32)*". Thanks a lot. Hao On Mon, Apr 12, 2010 at 5:42 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Hao Shen, > >> %4 = call float (i32)* (float (i32)*)* @get_ptr(float (i32)* @a1)

Hello A suggestion to LLVM (assembly) language designers. It could be worthwhile to extend the LLVM language http://llvm.org/docs/LangRef.html#i_call so that calls may return more than one result (for example, Common lisp functions can return more than one result). The intent could be to extend the ABI calling conventions to permit a function to return a few results (all in registers), instead of only one. The trade-off is to keep all the re...

...making them a 'language feature' of sorts. That's why they are intrinsics and not opcodes. >>3. Control transfer >> > LLVM has the 'call' instruction that abstracts the target machine's > calling convention. See http://llvm.cs.uiuc.edu/docs/LangRef.html#i_call > for more information. > Yes, it abstracts the target's C calling convention. But I'm trying to see if other types of languages can be implemented using LLVM. > What is that you are looking to express that isn't captured by the > `call' instruction? > Tail cal...

On Sunday 22 February 2009 20:36:52 Duncan Sands wrote: > Hi Jon, > > > I have written a variety tests of tail calls for my HLVM and all passed > > with flying colors until I wrote this test (which is actually for > > algebraic datatypes) and discovered that it segfaults after ~100k > > iterations through what I think should be a tail call. Here's the IR: >

I have some code generated with llvm-g++ and llvm-link that includes a tail call that is confusing me for two reasons: 1) I am not sure why it is a tail call (i.e. it does not look like it is in the tail position) 2) When I instrument the code using my opt pass, none of the instrumentation functions in the callee get called, leading me to believe that some funny business is going on. Below I

...se is managed by the compiler (saving into the stack, > getting result parameters, etc.) depending on the language's calling > conventions. LLVM has the 'call' instruction that abstracts the target machine's calling convention. See http://llvm.cs.uiuc.edu/docs/LangRef.html#i_call for more information. > In LLVM there's just one way to transfer control, and > the only proposal I've seen > (http://nondot.org/sabre/LLVMNotes/CustomCallingConventions.txt) keeps > this high level. This is to have more options for calling conventions that may be specified...

...arked "tail call" by the LLVM > > optimizers. So you also need to check under what conditions the LLVM > > optimizers do that. > > The backend does not check the following condition but assumes it to be > true. > > >From <http://llvm.org/docs/LangRef.html#i_call>: > > The optional "tail" marker indicates whether the callee function > accesses any allocas or varargs in the caller. If the "tail" marker is > present, the function call is eligible for tail call optimization. > Note that calls may be marked "tail&quot...

...these intrinsics COULD be made into opcodes, but it would add little value to do so. > >>3. Control transfer > >> > > LLVM has the 'call' instruction that abstracts the target machine's > > calling convention. See http://llvm.cs.uiuc.edu/docs/LangRef.html#i_call > > for more information. > > > > Yes, it abstracts the target's C calling convention. But I'm trying to > see if other types of languages can be implemented using LLVM. Sure they can. :) > > What is that you are looking to express that isn't captured by th...

On Tue, Mar 16, 2010 at 6:57 PM, Chris Lattner <clattner at apple.com> wrote: > > The "tail" marker has a very specific description in LLVM IR: it says that the caller does not access the callee's stack: > http://llvm.org/docs/LangRef.html#i_call Ah that makes more sense. Thanks for the pointer. > > 2) When I instrument the code using my opt pass, none of the instrumentation functions in the callee get called, leading me to believe that some funny business is going on. > I don't know about this. That is because I did not g...

Hi everybody, I'm currently looking at LLVM as a possible back-end to a dynamic programming system (in the tradition of Smalltalk) we are developing. I have read most of the llvmdev archives, and I'm aware that some things are 'planned' but not implemented yet. We are willing to contribute the code we'll need for our project, but before I can start coding I'll have to