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.
While that could be done, it would be redundant with existing
facilities. One of the key design criteria for LLVM is to keep its IR
"low level" and "not redundant". That is, when we introduce a facility
into the IR its because there is no other way to do it. A "thiscall"
instruction is completely redundant with a regular call that includes
the "this" argument.
This design is one of the reasons optimization passes are relatively
simple to write in LLVM. There aren't hundreds of special cases to
2) the ret instruction should be able to return structs (as Chris has
already written on his page)
Again, it can be implemented using a pointer argument. I'm not going to
lament this issue any more. While it would be convenient to return
structs from a front end point of view, its not convenient for LLVM or
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.
That needs to be done anyway (emitting code that meets the platform ABI
for exceptions), but I think you're still going to need to transmit some
kind of exception information through the LLVM IR. This is what the
invoke/unwind instructions were intended for. However, there are other
details that make exception handling language, front-end compiler, and
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.
I don't know what the design is, so its hard to say. If you've been
discussing this with Chris, he's out on vacation until Monday and will
probably respond then.