On Mon, Oct 5, 2009 at 8:27 PM, Axel Naumann <Axel.Naumann at cern.ch> wrote:> Hi, > > #include "JIT.h" will do.Thanks. That was exactly what I needed to progress to the next error ("Unable to find target for this triple (no targets are registered)") As soon as I get this front-end working with the trunk, I'll start submitting patches that add calls to the C-API; my front-end generates code-generation-code that relies on it rather heavily, and there are gaps I'd like to fill in.
On Mon, Oct 5, 2009 at 9:52 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote:> On Mon, Oct 5, 2009 at 8:27 PM, Axel Naumann <Axel.Naumann at cern.ch> wrote: >> Hi, >> >> #include "JIT.h" will do. > > Thanks. That was exactly what I needed to progress to the next error > ("Unable to find target for this triple (no targets are registered)")You probably need to call InitializeNativeTarget() or something. IMO, LLVM should probably do this by default as part of constructing a JIT. Reid> As soon as I get this front-end working with the trunk, I'll start > submitting patches that add calls to the C-API; my front-end generates > code-generation-code that relies on it rather heavily, and there are > gaps I'd like to fill in. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
My front-end is humming along beautifully now with the LLVM trunk. A few upgrade notes for anyone who is interested: 1. Not surprisingly, everything in your front-end needs to be recompiled; object layouts have changed. My generated code was calling some name-mangled stuff in the C++ libraries, and using struct/class definitions defined therein, and it fell over hard when I ran it against the trunk libraries. I ripped all that stuff out and added what I needed to the C bindings. 2. Linkage enums have changed. Since my front-end doesn't understand C, I had ported some LLVM definitions over so that I could use them in my language. That port, of course, was not automatically updated when I built against the trunk, so I ended up with global linkage settings that I wasn't expecting. This led to: 3. llc gets very unhappy if you give an unnamed global variable weak linkage. This is not surprising, since weak linkage uses name matching and doesn't make sense for things that have no name. Updating my linkage enum port cleared that up for me. 4. The set of library names to link against has changed considerably. 5. C bindings to ExecutionEngine stuff have moved out of libCore.a.
On Tue, Oct 6, 2009 at 2:39 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote:> My front-end is humming along beautifully now with the LLVM trunk. A > few upgrade notes for anyone who is interested: > > 1. Not surprisingly, everything in your front-end needs to be > recompiled; object layouts have changed. My generated code was > calling some name-mangled stuff in the C++ libraries, and using > struct/class definitions defined therein, and it fell over hard when I > ran it against the trunk libraries. I ripped all that stuff out and > added what I needed to the C bindings. > > 2. Linkage enums have changed. Since my front-end doesn't understand > C, I had ported some LLVM definitions over so that I could use them in > my language. That port, of course, was not automatically updated when > I built against the trunk, so I ended up with global linkage settings > that I wasn't expecting. This led to: > > 3. llc gets very unhappy if you give an unnamed global variable weak > linkage. This is not surprising, since weak linkage uses name > matching and doesn't make sense for things that have no name. > Updating my linkage enum port cleared that up for me. > > 4. The set of library names to link against has changed considerably. > > 5. C bindings to ExecutionEngine stuff have moved out of libCore.a. >6. When ExecutionEngine::create was called with parameter "GVsWithCode" set to its default value of true, I got a segfault when trying to get a pointer to one of my globals. JIT::getMemoryForGV was returning NULL in that case. Explicitly passing false for "GVsWithCode" cleared it up.