similar to: [LLVMdev] Help! Linking to external functions.

On Jan 8, 2013, at 13:55 , "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > You need to include 'llvm/ExecutionEngine/JIT.h' (or 'llvm/ExecutionEngine/JIT.h' if you want that engine) from your main file. Including that file forces the JIT static constructor to be linked into your executable. Without it, the JIT static constructor gets optimized out and

On Jan 10, 2013, at 22:10 , Sean Silva <silvas at purdue.edu> wrote: > On Thu, Jan 10, 2013 at 8:25 AM, Rick Mann <rmann at latencyzero.com> wrote: >> I've been writing up my experience embedding LLVM in a Cocoa app. If anyone would like to see it and give feedback, I'd appreciate it. It's still not finished, but the first part is there: >> >>

I've been writing up my experience embedding LLVM in a Cocoa app. If anyone would like to see it and give feedback, I'd appreciate it. It's still not finished, but the first part is there: http://roderickmann.org/stuff/LLVMTut/HowToEmbedLLVMWithXcode.html If it's worthy, hopefully it'll end up in the LLVM docs. -- Rick

On 27 Oct 2015, at 09:48, Senthil Kumar <senthil.thecoder at gmail.com> wrote: > > Haven't worked on this yet, but I work on the gcc AVR backend (and binutils), and I'm very interested in this - I intend to work on it in my spare time. And do you have any comments / objections to Dylan becoming the code owner? David

Exciting!!! > On Sep 29, 2015, at 17:03 , Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Dylan McKay via llvm-dev" <llvm-dev at lists.llvm.org> >> To: llvm-dev at lists.llvm.org, "David Siegel" <agnat at me.com> >> Sent: Thursday, September 3, 2015 10:35:16 PM >>

Hi list, Does LLVM provide support for Apple-style blocks? Or is that all implemented in clang using LLVM primitives? I'm looking at the IR that clang generates, and it sure seems confusing to me. I'm hoping there's a builder that can help me implement them. Thanks! -- Rick

On Feb 13, 2013, at 17:26 , Lang Hames <lhames at gmail.com> wrote: > LLVMContext was designed to support multithreading by holding the compilation context for each thread in a separate LLVMContext. If you're building modules in parallel you definitely need one LLVMContext per thread. > > If you're talking about compiling multiple modules sequentially with a single context

Several people have asked what the MC project is all about, and it is now getting to a point where it is pretty interesting and there are lots of potential projects for people who are interested. I wrote a big post about what it is here: http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html Thoughts and comments welcome, -Chris

Rick Mann <rmann at latencyzero.com> writes: > On Jan 8, 2013, at 13:55 , "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > >> You need to include 'llvm/ExecutionEngine/JIT.h' (or >> llvm/ExecutionEngine/JIT.h' if you want that engine) from your main >> file. Including that file forces the JIT static constructor to be >> linked

On Jan 10, 2013, at 14:21 , Justin Holewinski <justin.holewinski at gmail.com> wrote: > That's a very nice start! Do you plan on sandboxing the execution? It seems like just blindly executing the compiled code could easily crash the application if you have bad IR. I know that's a bit more advanced, but it would be nice to have some documentation on ways to sandbox the

I've been working through the getting started and language reference docs. One thing that's not immediately clear if it's possible is to define a global pointer to a specific memory address. I'm looking at ways to use LLVM to target a small ARM embedded processor, and there are a great many hardware registers mapped into the address space. I tried making a little sample C program

On Apr 9, 2010, at 23:32:12, Chris Lattner wrote: > Several people have asked what the MC project is all about, and it is now getting to a point where it is pretty interesting and there are lots of potential projects for people who are interested. I wrote a big post about what it is here: > http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html Thanks for the post, Chris. It

On Dec 12, 2013, at 04:25 , Gasiunas, Vaidas <vaidas.gasiunas at sap.com> wrote: > To address these requirements we have developed a set of patches improving performance and malfunction safety of certain compiler passes and would be interested in contributing them at some point. Before proposing concrete changes, we would like to know what the general interest is with respect to making

On Jan 17, 2013, at 19:33 , Eric Christopher <echristo at gmail.com> wrote: > You'll want to look at clang/lib/CodeGen/CGBlocks.[cpp, h]. Thanks. I think proper blocks are way over my head for my little project. I'll try to implement something "block-like" using function pointers. -- Rick

On Jan 23, 2013, at 21:47 , Sean Silva <silvas at purdue.edu> wrote: > Try running the verifier pass (the one that is invoked by `opt -verify`). I'm not sure how to do this. I'm writing a Cocoa app that calls the LLVM API directly; I don't use any of the command-line tools. Is there a way to verify via API? I think I've actually done this for individual types, dunno

Implementing my little language I'm using clang and the CPP back-end as a guide for a lot of things. One thing I see is that clang always uses Alloca and stores parameters on the stack. Are there LLVM passes that figure this out and put things in registers, skipping the stack allocations and loads/stores? Similarly, if I use Alloca to make room for a pointer on the stack, store a value in

On Thu, Jan 10, 2013 at 8:25 AM, Rick Mann <rmann at latencyzero.com> wrote: > I've been writing up my experience embedding LLVM in a Cocoa app. If anyone would like to see it and give feedback, I'd appreciate it. It's still not finished, but the first part is there: > > http://roderickmann.org/stuff/LLVMTut/HowToEmbedLLVMWithXcode.html This is great. People

Thanks for the response. If we add the support would you accept the patch? Seems like a pretty straightforward flag since it maps directly to NumericLiteralParser::NumericLiteralParser within LiteralSupport.cpp. I understand the maintenance concern with flags that affect multiple points in code though. Still trying to get the bottom of why we're crashing with double floating point literal.

> What's needed for CPU affinity? We expose his via pthread_attr_setaffinity_np() in <pthread_np.h> - > does the runtime need anything more from the interface, or was this support just not yet a high > priority for you? I'd be happy to help with this support. The Linux code uses the sched_{get,set}affinity calls directly, rather than via the pthread veneer. It can also

I wrote a little OS X app to assemble some LLVM (human-readable) code and run it. Unfortunately, my ExecutionEngine won't create. Just comes back NULL. This is the code that builds it: http://pastebin.com/8cexgPj7 This is the code it seems to successfully assemble, but it can't build the ExecutionEngine. You can see I tried several different ways of building it.