To help LDC/GDC

[Iain Buclaw]

On 8 April 2013 10:06, Timon Gehr <timon.gehr at gmx.ch> wrote:

> On 04/08/2013 10:29 AM, Iain Buclaw wrote:
>
>> On 6 April 2013 12:09, bearophile <bearophileHUGS at lycos.com
>> <mailto:bearophileHUGS at lycos.**com <bearophileHUGS at lycos.com>>> 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';
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130408/eccb3f89/attachment.html>