similar to: [LLVMdev] Code generation for compiler backend

I constructed an LLVM 2.7 VS solution with cmake, but it has 66 projects: ALL_BUILD, ".\ALL_BUILD.vcproj" BrainF, "examples\BrainF\BrainF.vcproj" Fibonacci, "examples\Fibonacci\Fibonacci.vcproj" FileCheck, "utils\FileCheck\FileCheck.vcproj" HowToUseJIT,

One thing that helps me understand complex software is a dependency graph. I found an LLVM dependency graph at https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_16/docs/UsingLibraries.html#dependencies but it's really messy and hard to follow. From that graph I made a cleaner graph by hand (attached)... sorry about the fax-quality scan. But I have some questions about it... -

Does not seem to be a straight error with LLVM itself, but rather the tools, linking issues, here are the errors: Opt: 30> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.exp 30>LLVMScalarOpts.lib(IndVarSimplify.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall

Where exactly is this mythical Kaleidoscope example? I have llvm 2.5 installed. examples dsw$ ls BrainF Fibonacci Makefile ParallelJIT CMakeLists.txt HowToUseJIT ModuleMaker > Date: Sat, 3 Oct 2009 21:40:44 +0100 > From: Renato Golin <rengolin at systemcall.org> > Subject: Re: [LLVMdev] LLVM-Kaleidoscope tutorial > > 2009/10/3 Remy Demarest <remy.demarest at

> > What's wrong with running LLVM on ARM? > > LLVM can generate code for ARM, but the JIT requires extra target and > platform dependent stuff, and that's not done for arm-wince. The release notes say "compiler_rt now supports ARM targets". What else is needed? Keep in mind that I do not need (or want) Clang or any of the optimizers: I just want to generate

I've recently upgraded my project-local copy of LLVM from 3.1svn to the latest 3.2svn, and all hell broke loose in my attempts to build OCaml projects. Trying to narrow it down, I tried testing examples/OCaml-Kaleidoscope and eventually test/Bindings, only to discover that literally nothing in the repository which uses the OCaml bindings seems to build in the current trunk: -

The linking issue is a recent breakage. I traced it back to r163175. Basically LLVMConstInlineAsm() got an additional parameter, but the C headers and the OCaml bindings were not updated accordingly. About the miscompilations, can you provide further details? Nuno ----- Original Message ----- > I've recently upgraded my project-local copy of LLVM from 3.1svn to the > latest

Hi, While building svn using CMake on an Ubuntu 9.04 system (gcc 4.3.3, binutils 2.19.1, 32-bit kernel and libs): Linking CXX executable ../../bin/llvm-dis [ 93%] Built target llvm-dis Scanning dependencies of target llc [ 93%] Building CXX object tools/llc/CMakeFiles/llc.dir/llc.cpp.o Linking CXX executable ../../bin/llc /usr/bin/ld: error in ../../lib/./LLVMX86AsmPrinter.o(.eh_frame); no

On Sep 7, 2012, at 3:40 PM, Nuno Lopes wrote: > The linking issue is a recent breakage. > I traced it back to r163175. Basically LLVMConstInlineAsm() got an additional parameter, but the C headers and the OCaml bindings were not updated accordingly. r163175 was my change. I'm not familiar with the OCaml project. If I'm responsible for updating said C headers/OCaml bindings, would

On Sep 10, 2012, at 3:34 PM, Bob Wilson wrote: > Didn't Benjamin already fix this in svn 163502? Looks that way.. > On Sep 10, 2012, at 10:08 AM, Chad Rosier <mcrosier at apple.com> wrote: > >> >> On Sep 7, 2012, at 3:40 PM, Nuno Lopes wrote: >> >>> The linking issue is a recent breakage. >>> I traced it back to r163175. Basically

Didn't Benjamin already fix this in svn 163502? On Sep 10, 2012, at 10:08 AM, Chad Rosier <mcrosier at apple.com> wrote: > > On Sep 7, 2012, at 3:40 PM, Nuno Lopes wrote: > >> The linking issue is a recent breakage. >> I traced it back to r163175. Basically LLVMConstInlineAsm() got an additional parameter, but the C headers and the OCaml bindings were not updated

Hi Dan, >Did the code in the tutorial work at some point? Offhand, I wouldn't expect >any of my recent changes to have affected this. I'm reluctant to fix this >without understanding how the original code was intended to work. The code works, but not as shown in the tutorial. In the tutorial, it shows that multiple calls to pure functions (sin, cos) can be optimized. Without the

Hi all, I downloaded LLVM to play with today and found that the BrainF example compiler fails with an assertion error like so: examples$ ./BrainF -jit /tmp/test.bf BrainF: Instructions.cpp:242: void llvm::CallInst::init(llvm::Value*, llvm::Value* const*, unsigned int): Assertion `(NumParams == FTy->getNumParams() || (FTy->isVarArg() && NumParams > FTy->getNumParams()))

Addendum: this still fails: auto ExprSymbol = J.findSymbol("putchard"); As yet, I have no idea why - that symbol even seemed to be exported: extern "C" double putchard(double X) { putchar((char)X); return 0; } On Fri, Apr 1, 2016 at 2:42 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > To try to find out why it was crashing, I followed the

To try to find out why it was crashing, I followed the trail of function calls: C:\llvm\examples\Kaleidoscope\Orc\initial\toy.cpp auto ExprSymbol = J.findUnmangledSymbol("__anon_expr"); JITSymbol findUnmangledSymbol(const std::string Name) { return findSymbol(mangle(Name)); } JITSymbol findSymbol(const std::string &Name) { return CompileLayer.findSymbol(Name,

On 20 March 2010 16:42, Russell Wallace <russell.wallace at gmail.com> wrote: > With Microsoft C++ (Windows Vista, 32-bit): > > LLVM 2.7 compiles (via cmake) without a hitch. > > I can't test it with my own code yet, will need to port from 2.6 to 2.7 > first. > > I was going to try running Kaleidoscope as a test case, but it doesn't > get built by default

Are the Kaleidoscope examples supposed to work on Windows? e.g. C:\llvm\examples\Kaleidoscope\Orc\initial\toy.cpp when I try to compile this with clang it gives compile time error messages, and when I try with Microsoft C++ it generates an executable that runs but crashes when I type in an expression; I get similar results with a few of the other versions. I can give more detailed feedback if

In the context of a JIT compiler, what's the recommended way to generate a call to an existing function, that is, not one that you are generating on-the-fly with LLVM, but one that's already linked into your program? For example the cosine function (from the standard math library); the Kaleidoscope tutorial recommends looking it up by name with dlsym("cos"), but it seems to me

> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] > On Behalf Of Russell Wallace via llvm-dev > Subject: [llvm-dev] JIT compiler and calls to existing functions > In the context of a JIT compiler, what's the recommended way to generate a call to an > existing function, that is, not one that you are generating on-the-fly with LLVM, but > one that's already

We use an explicit relocation step to deal with this. We generate code into a temporary memory location, then relocate it into a reserved area of memory which is always within a small relative offset of other interesting code. This allows us to get pc relative calls. Philip On 03/30/2016 05:53 AM, Matt Godbolt wrote: > For what it's worth we did a similar thing, but > overrode