search for: callvirt

Hello, Jeff. > and dereference it. But MSIL is at a higher level, where one simply > uses the callvirt instruction to do a virtual call and no vtable is > supplied or even present. You're right. Consider we will have some FE for MSIL, which will just generate LLVM's "call" instruction with some predefined CC, which will mean "this is virtual call". Backend can emit no...

Hello, Everyone. We've just commited new backend for LLVM: MSIL. The author of backend is Roman Samoilov from Codedgers Inc. (roman at codedgers.com). Backend itself is very similar to C backend (and actually was based on it). Note, it's pure LLVM-to-MSIL translator, so no additional checks etc. are performed. Backend is usable in general, but still lacks some important features: 1.

...> the hard part. This should be pretty hard. MSIL is definitely much more high level than LLVM, that's why significant portion of information will be lost during MSIL => LLVM (=lowered to vmkit-specific stuff), so I doubt that sane back reconstruction will ever be possible (consider e.g. callvirt instruction as an example). -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...This object model is explicitly part of MSIL semantics. LLVM is at a lower level; it does not have an object model. To do a virtual call, LLVM instructions must be generated to load a function pointer from a vtable and dereference it. But MSIL is at a higher level, where one simply uses the callvirt instruction to do a virtual call and no vtable is supplied or even present. There's no obvious way to reconstruct the higher level object semantics from LLVM IR, and sure enough the new MSIL back end never generates a callvirt instruction. In other words, it is incapable of using the .NET...

On Thu, 22 Mar 2007, Jeff Cohen wrote: > I'm confused. A MSIL front end I can understand, but a back end? How > will it be used? The GCC-based front ends that come with LLVM generate > bytecodes that have dependencies on the GCC runtime, which is not going > to be present in a .NET environment. Who said the input has to come through the GCC front-ends? Perhaps this is for

Dear Rudiger, Rüdiger Klaehn wrote: > Hello all. > > is it possible to use LLVM to optimize existing .NET assemblies? > It's in theory possible. LLVM+VMKit already does it for Java classes. > Basically doing the following: > > - read in MSIL and convert into LLVM internal representation > - perform global optimizations on LLVM internal representation > - write

...This should be pretty hard. MSIL is definitely much more high level > than LLVM, that's why significant portion of information will be lost > during MSIL => LLVM (=lowered to vmkit-specific stuff), so I doubt > that sane back reconstruction will ever be possible (consider e.g. > callvirt instruction as an example). OK. That is quite unfortunate. Does that mean that the existing LLVM MSIL backend does not work for complex LLVM programs? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090516/...

Hello, Jeff. > I'm confused. A MSIL front end I can understand, but a back end? How > will it be used? The GCC-based front ends that come with LLVM generate > bytecodes that have dependencies on the GCC runtime, which is not going > to be present in a .NET environment. Well. It's LLVM-to-MSIL translator. So, if the source use some unsupported code... The same situation

Hello all. is it possible to use LLVM to optimize existing .NET assemblies? Basically doing the following: - read in MSIL and convert into LLVM internal representation - perform global optimizations on LLVM internal representation - write out optimized MSIL using the existing LLVM backend I presume that the capability to convert MSIL into LLVM internal representation exists somewhere in VMKit.