similar to: [LLVMdev] llvm partly ported to windows

Hi everyone! I am working on a .NET based project (actually written in C#). During the coding, we have noticed many inefficiencies of C# compiler to optimize code. Compiler performs only a few optimisations. A vital optimisation, inlining, is missed. The JIT-er has rules not to inline methods containing structs as parameters (this is really stupid!) and inlining methods longer than 20 bytes

Hello, Žiga > I would like to compile at least x86 target as well as Fibonacci example > (to test if it really works). In order to do so, I may need some hints: > 1) How to generate X86GenRegisterNames.inc required by x86 (or any other > files, if there are any other) It's being built via tablegen > 2) Is bugpoint project buildable on windows? Yes. > 3) Which other tools

I was going through documentation and source lately, and I decided how to make llvm bytecode more compatible to C++: 1) thiscall sould be introduced, which would take N arguments and the first argument would always be the C++ "this" argument. This would abstract llvm compiler dependant C++ code emition. 2) the ret instruction should be able to return structs (as Chris has already

Hello, everyone! My name is Žiga Osolin and I am one of administrators of baadengine project (www.baadengine.org). It is an open source, BSD-licenced, game engine. We are very interested in llvm to provide us runtime code generation (basically, wrappers to easily call scripts from C++ and vica-versa, via vtbl (we replace vtbl for scripted types)) and also to allow our VM to run on llvm. Our

Hello! I have a question how about JIT-ed code and the C++ compiler compatibily. My project (www.baadengine.org) will use llvm and we will provide integration of JIT-ed code directly into C++ code. This means that C++ code can call JIT code just like any other code and JIT-ed code can call C++ code. We will compile to your bytecode from our BSF format. The question is if it is possible this

On Mon, 6 Nov 2006, [ISO-8859-2] Žiga Osolin wrote: > The other thing are the return types. I don't know (it is probably even > not documented) how VC++ returns smart pointer (boost::smart_ptr), > or any other type (other basics types, such as int, float, ... are > probably returned into EAX as with GCC). Once again, we may > need specific return values per arhitecture. It is

> On Mon, 6 Nov 2006, [ISO-8859-2] Žiga Osolin wrote: >> The other thing are the return types. I don't know (it is probably even >> not documented) how VC++ returns smart pointer (boost::smart_ptr), >> or any other type (other basics types, such as int, float, ... are >> probably returned into EAX as with GCC). Once again, we may >> need specific return values

Chris Lattner pravi: > On Tue, 21 Nov 2006, [ISO-8859-2] Žiga Osolin wrote: >>> Sure. Anton can give you ideas for this. >>> >> I think it should not be too difficult because you allow custom call >> conversions and this is quite easy to add, we only have to garantee that >> the backend will emit it. > > Right. > >>>> 2) the ret

Chris Lattner pravi: > On Tue, 21 Nov 2006, [ISO-8859-2] Žiga Osolin wrote: >> I was going through documentation and source lately, and I decided >> how to >> make llvm bytecode more compatible to C++: >> 1) thiscall sould be introduced, which would take N arguments and the >> first argument would always be the C++ "this" argument. This would >>

On Tue, 21 Nov 2006, [ISO-8859-2] Žiga Osolin wrote: >> Sure. Anton can give you ideas for this. >> > I think it should not be too difficult because you allow custom call > conversions and this is quite easy to add, we only have to garantee that > the backend will emit it. Right. >>> 2) the ret instruction should be able to return structs (as Chris has >>>

On Mon, 6 Nov 2006, [ISO-8859-2] Žiga Osolin wrote: > The problem is this is not possible, because what I would compile to JIT > are actual classes. The integration of C++ and JIT code is very > important; for example we would create our own vtbls with JIT-ed code > addresses as the function call target. Ok. Realize that this ties you to a specific compiler version though. >

On Tue, 21 Nov 2006, [ISO-8859-2] Žiga Osolin wrote: > I was going through documentation and source lately, and I decided how to > make llvm bytecode more compatible to C++: > 1) thiscall sould be introduced, which would take N arguments and the > first argument would always be the C++ "this" argument. This would > abstract llvm compiler dependant C++ code emittion. Sure.

Hi all, I've been following LLVM for a couple of years, and though I've not found an occasion to use it (yet), I'm always curious about its potential uses. I was discussing with friends about the Cell processor, and some of the arguments were that it is difficult to program and difficult to optimize. One of the concerns was that the PPE (central processor) is "in

I made the windows port, the first example compiled and executed correctly. I am sending a patch so you can test it if i didn't break linux compatibility. Otherwise, I will look into deja-gnu testing, perhaps can compile it on windows. I will also add other beckend in the future (Sparc, PowerPC). I hope windows using Visual C++ will be soon officially supported :) About the problem I had

On Sat, 18 Nov 2006, [ISO-8859-2] Žiga Osolin wrote: > I am currently trying to make EH (exception handling) possible to be > integrated in C++. This means that C++ code can throw exceptions and > llvm code can catch such exception and llvm can throw exceptions that > C++ can catch (or pass through). There are quite some difficulties with > approach: Cool! This is the major

Chris Lattner pravi: > On Sat, 18 Nov 2006, [ISO-8859-2] Žiga Osolin wrote: >> I am currently trying to make EH (exception handling) possible to be >> integrated in C++. This means that C++ code can throw exceptions and >> llvm code can catch such exception and llvm can throw exceptions that >> C++ can catch (or pass through). There are quite some difficulties with

Hi all, I'm a new user to LLVM. Not really sure if this is the correct place to post, since there isn't really any other forums around. Anyway, the issue I'm encountering is that, I was trying out the first tutorial (http://llvm.org/docs/tutorial/JITTutorial1.html). I attempted to do this in another folder that was copied from llvm/projects/sample. I created a new folder called

Hans, I have posted a complete patch for solving the linkage issues with LLVM_LINK_LLVM_DYLIB on Phabricator at http://reviews.llvm.org/D16945. The bulk of the fix the simple changes of... Index: cmake/modules/AddLLVM.cmake =================================================================== --- cmake/modules/AddLLVM.cmake (revision 259743) +++ cmake/modules/AddLLVM.cmake (working copy) @@

On Mon, Feb 8, 2016 at 12:45 PM, Hans Wennborg <hans at chromium.org> wrote: > Chris Bieneman is probably your best bet, and maybe also Dan Liew. > Hans, My current, and hopefully final, revision of the proposed patch is simplified and reworked to solve the problem entirely from cmake without touching the the llvm-build python scripts. Basically, the new fix for avoiding the

I realize my questions may not have been so clear. To give more details. I am writing a fuction pass. I want to interpret some of the instructions within the function pass. In order to do so, I need to create an EE object within the function pass. Now, If I compile and execute using opt. I get an error(Error loading symbol) at the line where I am creating EE. opt: symbol lookup error: