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 written on his page). 3) the EH could be done at code emission and would leave bytecodes portable. Each backend would emit code compatible (if possible) with the compiler it is compiled with; if llvm is compiled with VC8, it would emit code compatible with VC8. I will probably soon begin with development. Please let me know if there is any thing more I need to consider/know, or if there is someting wrong with the design. Also, any help (especially the thing with struct returns) would be very welcomed. In my opinion this is a big feature required by llvm. Regards, Žiga
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. Anton can give you ideas for this.> 2) the ret instruction should be able to return structs (as Chris has > already written on his page).This won't help C++ or C.> 3) the EH could be done at code emission and would leave bytecodes > portable. Each backend would emit code compatible (if possible) with the > compiler it is compiled with; if llvm is compiled with VC8, it would emit > code compatible with VC8.I agree for unwind tables, this is what the invoke/unwind abstraction are for. For RTTI, there is nothing the compiler can do to shield you from front-end dependencies. -Chris -- http://nondot.org/sabre/ http://llvm.org/
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 >> abstract llvm compiler dependant C++ code emittion. > > 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.>> 2) the ret instruction should be able to return structs (as Chris has >> already written on his page). > > This won't help C++ or C.I don't agree. For example: struct SmartPtr { void* px; shared* py; } Now, if I write the following method signature in C++: SmartPtr foo(int whatever); When I return, the llvm cannot return value in registers what is required by Visual C++ (or at least I think it is). I am posing this issue because I really need this feature in llvm for my project.> >> 3) the EH could be done at code emission and would leave bytecodes >> portable. Each backend would emit code compatible (if possible) with the >> compiler it is compiled with; if llvm is compiled with VC8, it would >> emit >> code compatible with VC8. > > I agree for unwind tables, this is what the invoke/unwind abstraction > are for. For RTTI, there is nothing the compiler can do to shield you > from front-end dependencies. > > -Chris > > ------------------------------------------------------------------------ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >