A
Andre Kaufmann
Willy said:| Willy Denoyette [MVP] wrote:
|
| >
| > #using <sub.dll>
|
| What is this line for ?
used to refer to the assembly containing the metadata of the class C, but I
guess you know that.
An assembly in an external DLL ? Yes I know that. I only asked to be
sure that it was no typo.
Do you really expect other IL code to be inlined
| by the C++/CLI compiler ? This compilation/inlining is part of the
| .NET runtime, why should this be optimized by the C++/CLI compiler ?
| Nobody wrote that global optimization should work over other languages /
| external DLL's too.
|
No, I know that they can't inline (existing) IL, and that's exactly my point
and what I tried to prove, but OK, I have two separate assemblies (a DLL and
an EXE) which is somewhat misleading.
Yes it's misleading.
Would one expect the C++ compiler to optimize code in an external DLL ? No.
With IL code theoretically it could be done - but since the DLL is
loaded at runtime the compiler would have to optimize the code at
runtime ?! IIRC the C++/CLI compiler is not part of the runtime and
therefore cannot do that.
The C++/CLI "only" optimizes the code of a single solution - only
"source" code - no binary IL code.
No one expected or said that it would also optimize code of other
compilers residing in a DLL.
Ok - let's simply forget about external "DLLs" ;-) and let do that a
future .NET framework compiler.
Now, I guess your sourcecode files looks like this (please correct me when
I'm wrong):
Not quite. I've not used only a header file.
That would be "normal" inlining. I've separated the code into CPP /
Header file.
My code looks like the following:
Header:
public ref class C
{
public:
int Square(int x);
};
CPP:
#include "sub.h"
int C::Square(int x)
{
return x*x;
}
#include "sub.h"
int main()
{
C^ c = gcnew C;
int r = c->Square(42);
System::Console::WriteLine(r);
}
Main is O.K.
It's true the call will be inlined, but this is one compiland (a sinle
source file)
Nope - 2 source files.
and is not what the article suggest [1]. The header file is
included in the one and only source file and then compiled, right?
No. As already said above it's separated in header and CPP file and only
a compiler with "link time" code generation is able to do that optimization.
< [1] article snip...
The compiler can now perform analysis and optimization across multiple
source files. Without WPO, for example, the compiler can only inline
functions within a single compiland. With WPO, the compiler can inline
functions from any source file in the program.>
now if you make it two compilands (two source files).
Like in my sample.
// file sub.h, common header
public ref class C
{
public:
int Square(int x);
};
// file sub.h
#include "sub.h"
int C::Square(int x)
{
return x*x;
}
// file main.cpp
#include "sub.h"
int main()
{
C^ c = gcnew C;
int r = c->Square(42);
System::Console::WriteLine(r);
}
And compile its using:
cl /c /clr:safe /O2 sub.cpp
cl /clr:safe /O2 main.cpp sub.obj
You see no inlining any more.
I wouldn't expect them to be inlined with /O2.
You don't use global optimization. Without that option the compiler
cannot do "global optimization" which is required for /GL and /LTCG
If you have other options, that would inline accross source files, I would
be happy to hear how.
/GL and /LTCG
Willy.
Andre