On 03/11/12 15:59, Manu wrote: > On 11 March 2012 16:01, Artur Skawina <art.08...@gmail.com > <mailto:art.08...@gmail.com>> 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.