digitalmars.D - Aliasing, and more
- bearophile (19/20) Oct 15 2009 I have discussed this topic a little in the past, but I didn't receive a...
I have discussed this topic a little in the past, but I didn't receive a good answer. So I try again explaining the situation better for Walter too. I don't need a full specs for the D1/D2 languages, but now and then a little more language specification helps. In C there are several undefined/unspecified things, that sometime allow for better optimizations on very different CPUs. But D tries to be less bug-prone, so it has to define more its behaviour. This may lead to a bit less performance (and in certain cases a lot less performance). When possible it's very good for D to have a syntax that allows the programmer to choose between a more predictable behaviour and a more aggressive optimization for performance (like in the case of uninitialized variables set to void. Generally it's better for the safer behaviour to be the default one). As Wikipedia says: http://en.wikipedia.org/wiki/Pointer_alias << In C, any function pointer argument may alias any other function pointer argument. The compiler must assume that any accesses through these pointers can alias. This dramatically restricts the potential for optimization. In C++, pointer arguments are assumed not to alias if they point to fundamentally different types ("strict aliasing" rules). This allows more optimizations to be done than in C. In C99, the "restrict" keyword specifies that a pointer argument does not alias any other pointer argument. This saves a little the situation for the C language, allowing more optimizations.See also: http://www.lysator.liu.se/c/restrict.html http://stackoverflow.com/questions/98340/what-are-the-common-undefinedunspecified-behavior-for-c-that-you-run-into In GCC there is also the "may_alias": http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Type-Attributes.html For performance you have to assume pointer not alias each other, this allows for better optimizations in several situations. But I use D to handle memory manually, for example using a pointer to point to different kinds of tagged structs, etc. (Sometimes for me the freedom to use memory in such low level way is the whole point of using D instead of Python/Java). Such operations are unsafe in C++ (well, in GCC you may use an union to stop the compiler to optimize things in the wrong way, or you can use the blunt tool of the "-fno-strict-aliasing" flag. So this is a very good situation where D can grow a standard and portable way (and syntax) to offer the programmer both performance and safety according to the different situations, something that you can do in C99 on GCC only in a nonportable way. D is in the position to improve this situation compared to C and C++. Even if the back-end of DMD isn't able to use such information, the backend of LDC is already able to use it, and future D compilers will have such information. So I think it has to be added. Bye, bearophile[I think the LLVM backend of LDC is able to use such information in a good way, if such information is available (currently it's not available, because I think D unfortunately doesn't offer such semantics yet).]
Oct 15 2009