Displaying 7 results from an estimated 7 matches for "llvm_function_new".
2004 Oct 06
1
[LLVMdev] generating function declarations in c frontend
...aration, so I tried
to just create one and add it to the globals list:
llvm_type *structTy, *ptrToStructTy;
structTy = llvm_type_create_struct(0, 0);
structTy = llvm_type_get_cannonical_struct(structTy);
ptrToStructTy = llvm_type_get_pointer(structTy);
llvm_function *dbg_stoppoint_fn = llvm_function_new(ptrToStructTy,
"llvm.dbg.stoppoint");
llvm_argument *arg = llvm_argument_new(structTy, "foo");
llvm_ilist_push_back(llvm_value, dbg_stoppoint_fn->Arguments, arg);
/* line # 548 */
llvm_ilist_push_back(llvm_global, TheProgram.Globals, dbg_stoppoint_fn);
This doesn...
2005 May 10
0
[LLVMdev] Scheme + LLVM JIT
...;
> What sort of interface should such an interface provide? The simplest
> is "pass-in-a-string-to-compile", but that's rather crude.
To me, the best interface is the most simple: I would suggest just
wrapping the llvm classes and methods you need with simple functions, e.g.
llvm_function_new/llvm_value_set_name/llvm_executionengine_run_function,
etc.
If kept simple, standardized, and generic, I think it would be very useful
to people (even if incomplete). This would allow others to build on it,
and we could 'ship' it as a standard llvm library.
-Chris
--
http://nondot.o...
2005 May 05
3
[LLVMdev] Scheme + LLVM JIT
> So as it stands, one should think of out JIT as something akin to the
> early Java JITs: one function at a time and only one compile per
> function. This is extremely primative by modern JIT standards, where a
> JIT will do profiling, find hot functions and reoptimize them,
> reoptimize functions when more information about the call tree is
> available, have several levels of
2005 May 12
2
[LLVMdev] Scheme + LLVM JIT
> llvm_function_new/llvm_value_set_name/llvm_executionengine_run_function,
> etc.
>
> If kept simple, standardized, and generic, I think it would be very useful
> to people (even if incomplete). This would allow others to build on it,
> and we could 'ship' it as a standard llvm library.
It...
2005 May 10
1
[LLVMdev] Scheme + LLVM JIT
On May 9, Chris Lattner wrote:
> To me, the best interface is the most simple: I would suggest just
> wrapping the llvm classes and methods you need with simple functions, e.g.
>
> llvm_function_new/llvm_value_set_name/llvm_executionengine_run_function,
> etc.
>
> If kept simple, standardized, and generic, I think it would be very useful
> to people (even if incomplete). This would allow others to build on it,
> and we could 'ship' it as a standard llvm library.
We...
2005 May 13
0
[LLVMdev] Scheme + LLVM JIT
On Thu, 12 May 2005, Alexander Friedman wrote:
>> llvm_function_new/llvm_value_set_name/llvm_executionengine_run_function,
>> etc.
>>
>> If kept simple, standardized, and generic, I think it would be very useful
>> to people (even if incomplete). This would allow others to build on it,
>> and we could 'ship' it as a standard l...
2005 May 18
1
[LLVMdev] Scheme + LLVM JIT
On May 16, Chris Lattner wrote:
>
> Sure, that sounds good. I'd definitely prefer that it be tested before it
> goes into CVS. Perhaps adding something to llvm/examples would be a good
> way to go.
>
> One suggestion, you might change the API to be something like this:
>
> ParseAsmString(const char *, Module *)
>
> Where the function parses the string and