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. There is no way to tell "import this function from that DLL file" to backend. Even more, there are no any equivalent of import libraries for MSIL code. So, in the future backend will include some "linking" pass, which will resolve external DLL references. Probably, we'll use nice set of .def files from public domain w32-api package (from Mingw32 folks). 2. Variable argument functions are unsupported now. 3. There is no support for dllimported variables (e.g. stdin, stdout, stderr symbols in MS runtime). 4. Also, backend completely lacks any testsuite. There are some small glitches here and there, but they are not so important as indicated ones. All indicated problems will be fixed in the nearest future. Any feedback, comments, questions are surely welcome. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.
Anton Korobeynikov wrote:> 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. >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.> Backend is usable in general, but still lacks some important features: > > 1. There is no way to tell "import this function from that DLL file" to > backend. Even more, there are no any equivalent of import libraries for > MSIL code. So, in the future backend will include some "linking" pass, > which will resolve external DLL references. Probably, we'll use nice set > of .def files from public domain w32-api package (from Mingw32 folks). >Some people have the official Microsoft files :) As it's apparent the developer does not have Visual Studio, how do you assemble and run the MSIL code? Do you use the utilities present in the .NET framework at all? (and, yes, they are free and frequently preloaded on new PCs, and Windows Update can install them on the rest.) That you would need to rely on Mingw32 implies you do not.> 2. Variable argument functions are unsupported now. > > 3. There is no support for dllimported variables (e.g. stdin, stdout, > stderr symbols in MS runtime). > > 4. Also, backend completely lacks any testsuite. > > There are some small glitches here and there, but they are not so > important as indicated ones. > > All indicated problems will be fixed in the nearest future. Any > feedback, comments, questions are surely welcome. > >
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 Jolt -> .NET? :) -Chris -- http://nondot.org/sabre/ http://llvm.org/
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 normal callvirt instruction in this case. I hope, many high-level things can be avoided using such tricks.> 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 framework library or anything else relying on virtual method calls.Well, I can be wrong. But if we will (possible) have some FE, which will try to save such semantics using LLVM methods? -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.
Anton Korobeynikov wrote:> 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 normal callvirt > instruction in this case. I hope, many high-level things can be avoided > using such tricks. >This trick is too clever for your own good. It will wreck LLVM's inter-procedural analysis, because it won't know the call is virtual. LLVM may make an invalid optimization due to the faulty analysis (like inlining the target). Trying to pass through MSIL object semantics in this fashion isn't likely to work for this and similar reasons.>> 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 framework library or anything else relying on virtual method calls. >> > Well, I can be wrong. But if we will (possible) have some FE, which will > try to save such semantics using LLVM methods? > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070323/f45d09a9/attachment.html>