<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

</head>

<body bgcolor="#ffffff" text="#000000">

Anton Korobeynikov wrote:

<blockquote cite="mid1174605871.23903.87.camel@asl.dorms.spbu.ru"

 type="cite">

  <pre wrap="">Hello, Jeff.

  </pre>

  <blockquote type="cite">

    <pre wrap="">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.

    </pre>

  </blockquote>

  <pre wrap=""><!---->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.

  </pre>

</blockquote>

<br>

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

<br>

<blockquote cite="mid1174605871.23903.87.camel@asl.dorms.spbu.ru"

 type="cite">

  <blockquote type="cite">

    <pre wrap="">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.

    </pre>

  </blockquote>

  <pre wrap=""><!---->Well, I can be wrong. But if we will (possible) have some FE, which will

try to save such semantics using LLVM methods?

  </pre>

</blockquote>

</body>

</html>