On 03/11/12 15:59, Manu wrote:
> On 11 March 2012 16:01, Artur Skawina <[email protected]
> <mailto:[email protected]>> wrote:
>
> > which I don't imagine D will be able to support any time real soon?
>
> In fact, until GDC learns cross-module inlining, using these modes is the
> only
> way to make the compiler generate sane code
>
>
> Yeah I'm very concerned by this currently. But it seems to we a well known
> issue with a plan/intent to fix it right?
> (Side note: I'd still really like an explicit @forceinline attribute)
Just '@forceinline' is IMHO too specific and not enough -- because you also
want
@noinline, @noclone, @flatten, @cold and more of theses kind of /generic/
attributes,
not to mention the target-specific ones. So a way to specify function (and data)
attributes is needed, together with a way to bundle them. Maybe something like
"alias @attr(noinline, noclone, cold, nothrow) @errorpath;".
> > ...and even then, relying on WPO for the language to generate good code
> in certain circumstances is a really really bad idea. This makes the task of
> implementing an efficient compiler for the language extremely difficult.
>
> There is a reason why i never even considered trying out a non-gcc-based
> D compiler... [1]
>
> For a language like D, WPO in some form is almost required; w/o it you'd
> need to
> always think about how the compiler will treat your code; which, while
> possible,
> would often result in more "unnatural" and tricky solutions. (In C/C++
> there's
> a *.h/*.c split, which helps mitigate the problem)
>
>
> "think about how the compiler will treat your code" ... "'unnatural' and
> tricky solutions" ... Outside of cross module inlining, what are some other
> common problem cases?
>
> C/C++ .h files only really simplify 2 things, inlining, and templates, but I
> can't see how the situation is any different in D?
Traditionally, the pre-WPO way, the coder would put the things expected to
become
part of the caller in header files. In D, header files are unnecessary, other
than
for the binary-lib-interface case. And currently even if you duplicate part of
the
code in a *.di file, it doesn't really change anything, other than preventing
some
optimizations like inlining or cloning (for the omitted parts).
If you have a complex data type which exports eg a range, you may want just
'.front'
etc to be inlined, and creating a *.di file just for this purpose shouldn't be
required. Template definitions need to be visible to the caller/user too -
having
to place them all in a *.di file would not be a good solution - in many cases
most of the code would move there...
Other than that, there is devirtualization - D does not have 'virtual'; the
compiler
can still do it and even inline the virtual methods, but it needs to know that
nothing overrides the functions - impossible w/o WPO for public non-final
classes. [1]
> My understanding is that templates depends on .d/.di files being present
> during compilation? So why doesn't D do inlining the same way? If I declare
> some inline function in a .d/.di file, surely it should be capable of
> inlining?
> C/C++ can't inline something from a foreign object either without a
> definition in a header...
It's the same for D, I just don't think *.di files should be necessary for
_internal_
cross-module interfaces, or when the full source is available anyway.
Currently, cross-module inlining is a problem for GDC, but even when that's
fixed,
WPO will help things like devirtualization or changing calling conventions (gcc
does
it already, but i don't know if it clones non-local functions just for this,
when not
in WPO mode).
artur
[1] BTW, this means that a "@virtual" attribute might be needed - to prevent
devirtualizing methods for classes used by plugins or other dynamically
loaded code.
