On Jun 17, 2009, at 9:46 AM, Paul Melis wrote:> FWIW, I'm also suddenly experiencing segfaults in code that used to > work > a few days ago (I'm using svn). This may be unrelated to the problem > described below, but perhaps it's the same thing. > > In my case it seems that creating an ExecutionEngine has changed. I > used > to do > > Module* Mod = makeLLVMModule(); // basically create a gcd > function > verifyModule(*Mod, PrintMessageAction); > > ExecutionEngine *EE; > EE = ExecutionEngine::create(Mod); > > but I now get 0x0 for EE. The compile command I'm using is > > g++ -O3 -I ~/llvm/include/ -L ~/llvm bug.cpp `llvm-config --cxxflags > --ldflags --libs core jit native` -o bug > > I noticed something very recently changed w.r.t. the way LLVM's > libraries are built (no more .o files). Could this have something to > with it?I *just* changed this. :) For JIT applications, please include llvm/Target/TargetSelect.h and call the llvm::InitializeNativeTarget() function before creating an EE. -Chris
Juan Carlos Martinez Santos
2009-Jun-17 17:43 UTC
[LLVMdev] Segmentation fault - Kaleidoscope
Hello, Maybe my version (LLVM 2.5) is incomplete... now get this error: toy.cpp:11:38: error: llvm/Target/TargetSelect.h: No such file or directory How can I get this file? Regards, Juan Carlos On Wed, Jun 17, 2009 at 12:51 PM, Chris Lattner <clattner at apple.com> wrote:> > On Jun 17, 2009, at 9:46 AM, Paul Melis wrote: > > > FWIW, I'm also suddenly experiencing segfaults in code that used to > > work > > a few days ago (I'm using svn). This may be unrelated to the problem > > described below, but perhaps it's the same thing. > > > > In my case it seems that creating an ExecutionEngine has changed. I > > used > > to do > > > > Module* Mod = makeLLVMModule(); // basically create a gcd > > function > > verifyModule(*Mod, PrintMessageAction); > > > > ExecutionEngine *EE; > > EE = ExecutionEngine::create(Mod); > > > > but I now get 0x0 for EE. The compile command I'm using is > > > > g++ -O3 -I ~/llvm/include/ -L ~/llvm bug.cpp `llvm-config --cxxflags > > --ldflags --libs core jit native` -o bug > > > > I noticed something very recently changed w.r.t. the way LLVM's > > libraries are built (no more .o files). Could this have something to > > with it? > > I *just* changed this. :) > > For JIT applications, please include llvm/Target/TargetSelect.h and > call the llvm::InitializeNativeTarget() function before creating an EE. > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Juan Carlos Martínez Santos 242 Foster Drive Apt H Colonial Townhouse Apartments Willimantic, CT 06226-1538 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090617/e8e71792/attachment.html>
Chris Lattner wrote:> On Jun 17, 2009, at 9:46 AM, Paul Melis wrote: > > >> FWIW, I'm also suddenly experiencing segfaults in code that used to >> work >> a few days ago (I'm using svn). This may be unrelated to the problem >> described below, but perhaps it's the same thing. >> >> In my case it seems that creating an ExecutionEngine has changed. I >> used >> to do >> >> Module* Mod = makeLLVMModule(); // basically create a gcd >> function >> verifyModule(*Mod, PrintMessageAction); >> >> ExecutionEngine *EE; >> EE = ExecutionEngine::create(Mod); >> >> but I now get 0x0 for EE. The compile command I'm using is >> >> g++ -O3 -I ~/llvm/include/ -L ~/llvm bug.cpp `llvm-config --cxxflags >> --ldflags --libs core jit native` -o bug >> >> I noticed something very recently changed w.r.t. the way LLVM's >> libraries are built (no more .o files). Could this have something to >> with it? >> > > I *just* changed this. :) >Hmm, I can see your commits from a few hours ago, but something was already up a bit earlier. Anyways...> For JIT applications, please include llvm/Target/TargetSelect.h and > call the llvm::InitializeNativeTarget() function before creating an EE. >I just svn up-ped to r73620, recompiled and reinstalled LLVM and still got 0x0 for the execution engine instance. Found the problem: I didn't include "llvm/ExecutionEngine/JIT.h" Paul
On Jun 17, 2009, at 10:43 AM, Juan Carlos Martinez Santos wrote:> Hello, > > Maybe my version (LLVM 2.5) is incomplete... now get this error: > > toy.cpp:11:38: error: llvm/Target/TargetSelect.h: No such file or > directory > > How can I get this file?This only exists on mainline. -Chris
Hi,
Why are there so many undocumented (and as I far I can see) unnecessary
API changes?
Recently there has been:
1.
For JIT applications, please include llvm/Target/TargetSelect.h and
call the llvm::InitializeNativeTarget() function before creating an EE.
2.
The major CHANGE is: the JIT will no longer be safe for executing
threaded applications without first invoking llvm_start_multithreaded().
Please begin to update your client applications now if this affects
you, as I will be throwing the switch in SVN sooner rather than later.
3.
The change you should make: every call to addPassesToEmitFile,
addPassesToEmitFileFinish, addPassesToEmitMachineCode, or
addCommonCodeGenPasses should pass an optimization level enum rather
than true / false for "Fast". The enum is in
llvm/Target/TargetMachine.h:
namespace CodeGenOpt {
enum Level {
Default,
None,
Aggressive
};
}
4.
The LLVM IR opcodes Add, Sub, and Mul have been each split into two.
Add, Sub, and Mul now only handle integer types, and three new opcodes,
FAdd, FSub, and FMul now handle floating-point types.
And that's just in a few days!
I recently tried to build my compiler-generator with the svn-head
version of llvm.
No chance.
It wouldn't build, thanks to (3) above.
Once I got it to build, it crashed.
It all works just fine with 2.5.
I spent a lot of time and effort, getting things to work, first with
2.4, then with 2.5 (The changes in the API between 2.4 and 2.5 were more
than I would have liked, but mainly renaming and caught by the compiler).
Remember, its not just gcc-llvm and clang that use llvm.
So please treat the API with respect.
Don't change it often, and document EACH and EVERY change.
PS.
Change (1) above seems to be pointless.
Why can't the code to create the EE, just call
llvm::InitializeNativeTarget()?
Mark.
Chris Lattner wrote:> For JIT applications, please include llvm/Target/TargetSelect.h and > call the llvm::InitializeNativeTarget() function before creating an EE.Couldn't the EE creation functions do this call automatically if no target has been set yet, instead of just returning a null pointer? For the sake of backward compatibility. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag
Hi Mark,> 3. > The change you should make: every call to addPassesToEmitFile, > addPassesToEmitFileFinish, addPassesToEmitMachineCode, or > addCommonCodeGenPasses should pass an optimization level enum rather > than true / false for "Fast". The enum is in > llvm/Target/TargetMachine.h: > > namespace CodeGenOpt { > enum Level { > Default, > None, > Aggressive > }; > } >We needed a finer-grained control over what optimizations are run during the code generation passes. Some optimizations aren't appropriate for the Default case, but are for the Aggressive case. I can't comment on the other changes. But in general, the llvm development trunk is in a state of perpetual flux. It only settles down around release time. Also, our APIs aren't written in stone, which is by design. The downside of this is that people who use our APIs may have to change their code from release to release. And if you live on the development trunk, it takes a lot of maintenance to keep up (as you found out). We do try to document, or at least warn, about every change we make. But that documentation tends to be from release to release. -bw
On Jun 17, 2009, at 12:23 PM, Albert Graef wrote:> Chris Lattner wrote: >> For JIT applications, please include llvm/Target/TargetSelect.h and >> call the llvm::InitializeNativeTarget() function before creating an >> EE. > > Couldn't the EE creation functions do this call automatically if no > target has been set yet, instead of just returning a null pointer? For > the sake of backward compatibility.No, the whole point of this is to make it trivial for a JIT to link in just the code generator it needs. If the EE depended on all the targets, then all the targets would have to get linked in. This would be bad for code size reasons among other things. -Chris
On Jun 17, 2009, at 12:06 PM, Mark Shannon wrote:> Why are there so many undocumented (and as I far I can see) > unnecessary > API changes?They are only seem unnecessary if you don't understand the reason they were made. We don't make change for change's sake :)> Recently there has been: > > 1. > For JIT applications, please include llvm/Target/TargetSelect.h and > call the llvm::InitializeNativeTarget() function before creating an > EE.This fixes long standing linkage problems and helps us move forward with cmake.> 2. > The major CHANGE is: the JIT will no longer be safe for executing > threaded applications without first invoking > llvm_start_multithreaded(). > Please begin to update your client applications now if this affects > you, as I will be throwing the switch in SVN sooner rather than later.I don't believe that this is true anymore. However, the reason for this series of changes is to make LLVM multithread safe, so that you can have multiple threads JIT'ing at the same time etc.> 3. > The change you should make: every call to addPassesToEmitFile, > addPassesToEmitFileFinish, addPassesToEmitMachineCode, or > addCommonCodeGenPasses should pass an optimization level enum rather > than true / false for "Fast". The enum is in > llvm/Target/TargetMachine.h:This was made to give more control over optimization level.> 4. > The LLVM IR opcodes Add, Sub, and Mul have been each split into two. > Add, Sub, and Mul now only handle integer types, and three new > opcodes, > FAdd, FSub, and FMul now handle floating-point types.This is to allow LLVM IR to more accurately model integer overflow, which is very important for loop optimization (particularly on 64-bit platforms).> And that's just in a few days!LLVM moves quickly :)> I spent a lot of time and effort, getting things to work, first with > 2.4, then with 2.5 (The changes in the API between 2.4 and 2.5 were > more > than I would have liked, but mainly renaming and caught by the > compiler). > > Remember, its not just gcc-llvm and clang that use llvm. > > So please treat the API with respect. > Don't change it often, and document EACH and EVERY change.You'll notice that llvmdev was notified about all of these changes.> Change (1) above seems to be pointless. > Why can't the code to create the EE, just call > llvm::InitializeNativeTarget()?Because InitializeNativeTarget() is actually more about linking than initializing. You'll notice that all the targets have empty implementations of this method. However, if you don't call this, the (e.g.) X86 backend won't get linked into your app. I'm sorry about API changes, but change is an inherent part of making LLVM better. We will aim to document them in the 2.6 release notes. -Chris
On Jun 17, 2009, at 12:06 PM, Mark Shannon wrote:> 2. > The major CHANGE is: the JIT will no longer be safe for executing > threaded applications without first invoking llvm_start_multithreaded > (). > Please begin to update your client applications now if this affects > you, as I will be throwing the switch in SVN sooner rather than later. >This one is necessary for the ongoing work to make the LLVM APIs thread-safe. Because of portability issues (mostly concerned with differences between Windows and Unix-like systems), this is the only acceptable way we have found to ensure that the necessary guard structures are allocated and available when they are needed.> Remember, its not just gcc-llvm and clang that use llvm. > > So please treat the API with respect. > Don't change it often, and document EACH and EVERY change.I'm not sure exactly what you're getting at here. If anything, I've been very impressed in the recent days with the effort people are putting in to announce their API-breaking changes. It's much improved from the old days of no notice breakage. The API can and will evolve over time, and we're making efforts to make it easier for client programs to keep up by announcing API changes, including recipes for how to deal with them, in an obvious manner in advance of the change itself. --Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090617/0d6e0321/attachment.html>
Hi Mark,> Why are there so many undocumented (and as I far I can see) unnecessary > API changes?these can now be documented in docs/ReleaseNotes-2.6.html. Ciao, Duncan.> > Recently there has been: > > 1. > For JIT applications, please include llvm/Target/TargetSelect.h and > call the llvm::InitializeNativeTarget() function before creating an EE. > > 2. > The major CHANGE is: the JIT will no longer be safe for executing > threaded applications without first invoking llvm_start_multithreaded(). > Please begin to update your client applications now if this affects > you, as I will be throwing the switch in SVN sooner rather than later. > > 3. > The change you should make: every call to addPassesToEmitFile, > addPassesToEmitFileFinish, addPassesToEmitMachineCode, or > addCommonCodeGenPasses should pass an optimization level enum rather > than true / false for "Fast". The enum is in > llvm/Target/TargetMachine.h: > > namespace CodeGenOpt { > enum Level { > Default, > None, > Aggressive > }; > } > > 4. > The LLVM IR opcodes Add, Sub, and Mul have been each split into two. > Add, Sub, and Mul now only handle integer types, and three new opcodes, > FAdd, FSub, and FMul now handle floating-point types. > > And that's just in a few days! > > I recently tried to build my compiler-generator with the svn-head > version of llvm. > No chance. > It wouldn't build, thanks to (3) above. > Once I got it to build, it crashed. > It all works just fine with 2.5. > > I spent a lot of time and effort, getting things to work, first with > 2.4, then with 2.5 (The changes in the API between 2.4 and 2.5 were more > than I would have liked, but mainly renaming and caught by the compiler). > > Remember, its not just gcc-llvm and clang that use llvm. > > So please treat the API with respect. > Don't change it often, and document EACH and EVERY change. > > PS. > > Change (1) above seems to be pointless. > Why can't the code to create the EE, just call > llvm::InitializeNativeTarget()? > > Mark. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev