similar to: [LLVMdev] llvmdev: Windows support

> 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

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. >

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

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 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

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

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 >>

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

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 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.

Hello (again)! I fixed most of the system and the following projects compile now: * Analysis * AsmParser * Bytecode * CBeckend * Codegen * ExecutionEngine * Support * System * TableGen * Target * Transforms * VMCore 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

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. 2) the ret instruction should be able to return structs (as Chris has already

I was wondering if (and when) is the full C++ compiling support (as it was with llvm3) to be expected (this mainly means the addition of EH to llvm)? Regards, Žiga

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

> Otherwise, I will look into deja-gnu testing, perhaps can compile it on > windows. I will The deja-gnu testing framework will most likely have to be rewritten to run on Windows. Its very unix specific. -Tanya > 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 with

Hello! 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: * I must write ABI specific backends for EH. Since we support Visual Studio and GCC, two

I took the output of clang, simplified it, and used it as a testbase. Essentially, there is one class with one virtual function; I create an instance and call the virtual method all in one function: ; The TestVirtual class vtbl @classvtbl.TestVirtual = constant %classvtbltype.TestVirtual { ; Pointers to the virtual methods for the TestVirtual class ... } ; ... define i32 @main() nounwind { ;

On Mon, Oct 11, 2010 at 12:30 PM, John McCall <rjmccall at apple.com> wrote: > On Oct 11, 2010, at 9:12 AM, Kenneth Uildriks wrote: >> 3. The front-end, recognizing that scribbling on an instance's vtbl >> pointer has undefined results, eliminated the loads of the vtbl >> pointer and replaced them with @classvtbl.TestVirtual.  This would >> allow

On Oct 11, 2010, at 9:12 AM, Kenneth Uildriks wrote: > 3. The front-end, recognizing that scribbling on an instance's vtbl > pointer has undefined results, eliminated the loads of the vtbl > pointer and replaced them with @classvtbl.TestVirtual. This would > allow devirtualization within a function at least, but (I think) would > do less to allow analysis to spot