llvm dev - Feb 2015 - [LLVMdev] Any mechanism available for link time inlineing?

Hi,

trying to develop this idea of splitting c++ classes into real interface
and implementation and to make a std isocpp proposal out of it. Need some
help and info to make the proposal cover as many details as possible.

The idea is to split the class declaration into a part that will stay in
the header and will contain only the public members. (let's ignore
protected for the moment). The c++ part will contain the private stuff
including private data. The part in the header I call for simplicity white
and the part in the C++ black (from blackbox vs. whitebox).

Having this in place could reduce compilation time, open a simple way for
classes in DLL, etc. etc. I know about modules, reflection, I know, etc.
let's don't introduce for the moment noise.

Two main problems come from the idea above are sizeof() (for allocation,
passing by value/reference) and offsets of data members. Let's ignore for
the moment sizeof related problems and just look at offsets.

At the moment if we have
class A {
  private:
      MyType data;

   public:
      MyType &getData() {return data}
      void setData(MyType &in) {data = in;}
};

The above setters/getters can be easily inlined by the compiler to avoid a
function call for such a trivial case.

/* inside A.h */
class white A {
   public:
      MyType &getData() {return data}
      void setData(MyType &in) {data = in;}
};

/* inside A.cpp */
class black A {
   public:
            MyType data;
};


The problem is that in the model I am proposing the layout of the class is
not available at compilation time, for consumers of A.h other than A.cpp.
It will be only available at link time.

Now the question: is there any mechanism available/proposed to do the
inlining at static or dynamic linking phase? The question refers both to
LLVM, or other compilers. Well, the idea would be that LLVM generates some
placeholder that could be easily identified by the static/dynamic linker
and replaced by the inlined function readily baked. Probably the size of
the code to patch has to have fixed length etc. In the case above the
compiler will generate the inline code for the getter setter from A.cpp
based on the offset information it knows. The linker should glue together
the parts.

I am aware about the non -fPIC way of linking functions from dynamic
libraries, which seems to be an abandoned direction.

Thanks for help, and please ask questions if my brief presentation is not
clear

regards,
mobiphil
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150209/b839c641/attachment.html>

sorry to insist. While I do not beleive the question was the dumbest in the
world, would love to know to find out some info, please find belowe the
short version of the question:

Is there already in LLVM or is there any plan to support some mechanism for
static/dynamic inline-ing?

thanks a lot
mobiphil
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150212/ceb5174e/attachment.html>

> On Feb 12, 2015, at 8:15 AM, mobi phil <mobi at mobiphil.com> wrote:
> 
> sorry to insist. While I do not beleive the question was the dumbest in the
world, would love to know to find out some info, please find belowe the short
version of the question:
> 
> Is there already in LLVM or is there any plan to support some mechanism for
static/dynamic inline-ing?
It is already statically possible at link-time using LTO. I *think* it is
enabled by default looking at
https://llvm.org/svn/llvm-project/llvm/trunk/tools/llvm-lto/llvm-lto.cpp
Try googling “LLVM LTO inlining” for more info.

Mehdi