<div dir="ltr"><div>Oleg,</div><div><br></div><div>May be I am misunderstanding what you're saying... <br></div><div><div>Since I am proposing a different framework for execution,</div></div><div>the architecture which has an abstract machine <br></div><div>and a memory model will have to change. <br></div><div>Since I'd like to have remote objects,</div><div>which are native to C++, unlike the existing objects, which are all local,</div><div>I am proposing this IOR layer. Access to objects will have to change.</div><div>An object access will not longer be a memory access, unless some</div><div>compiler optimization determines that the object is local.</div><div><div>So this probably means that it requires changes to the LLVM IR?</div><div>As I said, I don't know enough about the current LLVM architecture</div><div>to make a detailed plan, but I think it is an interesting problem.<br></div></div><div><br></div><div>Ed<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 28, 2018 at 5:42 PM Oleg Smolsky <<a href="mailto:oleg@cohesity.com">oleg@cohesity.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018-11-28 13:14, Edward Givelberg via cfe-dev wrote:<br>
><br>
> [...]<br>
> Naively, it seems to me that LLVM is a sequential VM, so perhaps its <br>
> architecture needs be extended.<br>
> I am proposing an intermediate representation which encodes object <br>
> operations,<br>
> let's call it IOR. IOR is translated to interconnect hardware <br>
> instructions, as well as LLVM's IR.<br>
> I am proposing a dedicated back end to generate code for the <br>
> interconnect fabric.<br>
<br>
Edward, it sounds to me like you are trying to reinvent Smalltalk. Its <br>
core is really about message passing and perhaps people have made <br>
attempts to make it parallel already.<br>
<br>
On a more serious and specific note, I think you are ignoring the <br>
"abstract C machine" on which both C and C++ languages are built. <br>
Fundamentally, objects are laid out in memory (let's ignore the stack <br>
for now) and are built off primitive and user-defined types. These types <br>
are known (and stable) throughout the compilation process of a single <br>
program and so are the offsets of various fields that comprise the <br>
objects. All these objects (and often their sub-objects) can be read and <br>
written anywhere in a single-threaded program. Multi-threaded programs <br>
must be data-race-free, but essentially follow the same model.<br>
<br>
The point I am trying to make is that the whole model is built on memory <br>
accesses that are eventually lowered to the ISA. There is no rigid <br>
protocol for invoking a member function or reading a member variable - <br>
things just happen in the program's address space. And then there is <br>
code optimizer. The memory accesses (expressed via LLVM IR, for example) <br>
go through various techniques that reduce and eliminate pointless <br>
work... at which point you have the target's ISA and absolutely no <br>
notion of a "method" or "object" (as a well-formed program cannot tell <br>
that the code has been re-arranged, reduced, reordered etc).<br>
<br>
I suggest that you take a look at <a href="https://godbolt.org" rel="noreferrer" target="_blank">https://godbolt.org</a> and see what the <br>
compiler emits with -O3 for a few short class/function templates as well <br>
as normal procedural code.<br>
<br>
Oleg.<br>
<br>
</blockquote></div>