On 8 April 2013 10:06, Timon Gehr <[email protected]> wrote: > On 04/08/2013 10:29 AM, Iain Buclaw wrote: > >> On 6 April 2013 12:09, bearophile <[email protected] >> <mailto:bearophileHUGS@lycos.**com <[email protected]>>> wrote: >> >> I remember Walter saying two or more times that the semantics of D >> offers some optimization opportunities that probably are not yet >> used to try to reduce the run-time of D programs. Is Walter willing >> to write down a list of such opportunities? (Ideas from other >> persons are welcome). Maybe some LDC/GDC developer will make the >> GCC/LLVM back-ends use them. The implementation of those ideas will >> require some time, so later it's better to put the list in the D wiki. >> >> Bye, >> bearophile >> >> >> >> This information could possibly be helpful. Though given that most of >> (gdc) codegen is on par with g++, there's probably not much on the list >> that isn't already detected by the backend optimisation passes. >> >> >> -- >> Iain Buclaw >> >> *(p < e ? p++ : p) = (c & 0x0f) + '0'; >> > > Does GDC use the additional type information for optimization? Eg. if > something is immutable, then aliasing issues do not have to be considered > for it when reading and writing through multiple pointers repeatedly. >
It uses some type information, eg: const/immutable/wild -> qualified const. shared -> qualified volatile. shared + const/wild -> qualified const/volatile. Done nothing in regards to C 'restrict' optimisations. However the D array .ptr type could also be considered 'restrict' also. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
