On 03/11/12 02:27, Manu wrote: > I've never seen the compiler do wildly unexpected things unless whole program > optimisation is enabled
The compiler can only ignore the ABI when it knows it sees the whole picture, ie whole program, or whole unit in case of private/local functions. > which I don't imagine D will be able to support any time real soon? Umm, GDC supports WPO, both as LTO and "std" WPO, though i don't remember if i ever tried the latter. In fact, until GDC learns cross-module inlining, using these modes is the only way to make the compiler generate sane code, w/o reverting to turning all D functions into templates or compiling all sources together (at which point you could just as well turn on WPO...). Also, unit-at-a-time, which is on by default, can help. It (gdc) still has a few LTO bugs which sometimes cause trouble, but often can be worked around. And you may need to use the *.d runtime files (instead of *.di) etc. > ...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) artur [1] LLVM is possibly an option too, but i haven't yet found the time to investigate.
