similar to: [LLVMdev] [PATCH] Link in codegen components in llvm-c

Hello, [Using LLVM r155315, according to `svn log | head`] I am experimenting with programatically building and jitting functions in a module, and I seem to be coming across a crash in some generated code. Using the llvm-c interface I build up the module which dumps like this: ; ModuleID = 'MyModule' target datalayout = "i686-apple-darwin11" target triple =

Hi David, I'm not certain, but to me the "LLVMSetTarget(module, "i686-apple-darwin11");" line looks suspicious. I'm not familiar with all the ins and outs of how target triples get handled, but it looks to me like that's requesting 32-bit code. I think that if you omit that line completely then the target will be inferred from the execution environment. My best

Hi, I'm attempting to use MCJIT with the C interface with llvm-3.9.0, and it doesn't seem to work. This code is derived from Paul Smith's example code: int main(int argc, char const* argv[]) { LLVMModuleRef mod = LLVMModuleCreateWithName("my_module"); LLVMTypeRef param_types[] = {LLVMInt32Type(), LLVMInt32Type()}; LLVMTypeRef ret_type =

Thanks for the tip - getting closer: $ ./capi_test 5 6 args[0]: 5 args[1]: 6 result: 4294959200 Here's the code I changed: printf("args[0]: %d\n", (int)LLVMGenericValueToInt(args[0], 0)); printf("args[1]: %d\n", (int)LLVMGenericValueToInt(args[1], 0)); uint64_t (*func)(); func = (uint64_t (*)())LLVMGetFunctionAddress(engine, "sum");

I'm using the llvm-c API and want to use the JIT. I've created the following module ; ModuleID = '_tmp' @a = global i64 5 define i64 @__tempfunc() { entry: %a_val = load i64* @a ret i64 %a_val } This output is generated by LLVMDumpModule just before I call LLVMRunFunction. Which yields a LLVMGenericValueRef. However converting the result to a 64bit integer via

Hello, I have a question concerning llvm-c. I have set up a function that needs to invoke an external method, in a other library. It has the following signature: void* NSFullUserName(void); The void* can be replaced with a i8*, that far I was able to get, but when my call is invoked, the engine gives me the following message: LLVM ERROR: Tried to execute an unknown external function: i8* ()*

Hi All, Here is the code from bindings/ocam/executionengine/executionengine_ocaml.c. /* llvalue -> GenericValue.t array -> ExecutionEngine.t -> GenericValue.t */ CAMLprim value llvm_ee_run_function(LLVMValueRef F, value Args, LLVMExecutionEngineRef EE) { unsigned NumArgs; LLVMGenericValueRef Result, *GVArgs; unsigned I; NumArgs =

With the TableGen problem circumvented the build proceeds quite well up until: llvm[2]: Linking Debug executable llc /home/neale/LLVM/llvm/tools/llc/Debug/llc.o: In function `ForceCodegenLinking': /home/neale/LLVM/llvm/include/llvm/CodeGen/LinkAllCodegenComponents.h:45: undefined reference to `llvm::createBURRListDAGScheduler(llvm::SelectionDAGISel*, bool)'

Hello, Neale > These entry points are in modules that have been compiled and placed into an > archive. (e.g. llvm::createBURRListDAGScheduler is in ScheduleDAGRRList.cpp > whose object is placed in ./Debug/lib/libLLVMSelectionDAG.a). > > I'm sure I've missed a configuration option or something trivial like that > but my newbie brain can't determine what it is. make

Quoting Bill Wendling <isanbard at gmail.com>: > Hi Nikolaos, > > I have an alpha version of Chow & Hennesey's priority-based graph > coloring algorithm. It's suffering from some bit-rotting -- e.g., > there's some trouble with how it calculates "forbidden" registers. > You're welcome to the code, if you'd like to hack on it. I've been

William Morgan wrote: > Hi all, > > At the bottom of chapter 8 of the tutorial, on the topic of closures, > mentions that there are "often better ways to implement these features > than explicit stack frames". Does anyone know what techniques this > cryptic statement might be referring to? > > Thanks! > I would say it means to have a "stackless"

Hi all! I didn't manage to link my regalloc to lli (I added USEDLIBS to its makefile). Without it I can't run tests cause they need lli to be built. So how can I link createMyRegisterAllocator function to lli? Thanks. On 8/22/06, Anton Vayvod <avayvod at gmail.com> wrote: > > I managed to link my RegAlloc.a library to llc tool but can;t make the > same with lli tool.

Hi all, At the bottom of chapter 8 of the tutorial, on the topic of closures, mentions that there are "often better ways to implement these features than explicit stack frames". Does anyone know what techniques this cryptic statement might be referring to? Thanks! -- William <wmorgan-llvm at masanjin.net>

Hi! I'm developing a register allocator and need it to be available as an option for llc tool. I used to edit /lib/CodeGen/Passes.cpp for this aim but after yesterday's update these options are defined somewhere else and I can't find the place. Thanks for your help. Tony. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello, I''m new to ruby and rails and am simply trying to install. I have a Windows XP machine and have installed ruby on c:ruby along with gem. I have also downloaded the rails-1.1.2.gem file but when I run gem install rails --include-dependencies ,I get the following: Attempting local installation of ''rails'' ERROR: Error installing gem rails[.gem]: rails

On Aug 12, 2010, at 10:43 AM, F van der Meeren wrote: > Where am I going wrong here? > Did you link against the library that contains the function? -eric

Welcome to the world of pluggable machine passes. This work was done to lighten the load of some llvm tools, ie., only link in the register allocators and instruction schedulers that are actually needed in a particular circumstance. I guess I will have to write this up, but generally it works like this. In your register allocator .cpp file add the following include; #include

On Sat, 2 Sep 2006, Anton Vayvod wrote: > I didn't manage to link my regalloc to lli (I added USEDLIBS to its > makefile). Without it I can't run tests cause they need lli to be built. So > how can I link createMyRegisterAllocator function to lli? Make sure to add it to Codegen/LinkAllCodegenComponents.h. -Chris > On 8/22/06, Anton Vayvod <avayvod at gmail.com> wrote:

On 9/2/06, Chris Lattner <sabre at nondot.org> wrote: > > Make sure to add it to Codegen/LinkAllCodegenComponents.h. I'm sure I did. I did so from the first time and I also needed to add my library .a file to the USEDLIBS variable within llc makefile to build llc. I wonder how lli links with all the rest LLVM as it seems to include no lib within its makefile. May be I need to

I've completed a survey of llvm for unnecessary dependencies on libstdc++, and on conflicts with the upcoming C++0X standard, and am recommending several changes in the enclosed patch (created with svn diff). Here is a summary of the patch: --- #include <cstdlib> added to LinkAllVMCore.h and LinkAllCodegenComponents.h to declare std::getenv. Changed next(...) to llvm::next(...) in