To help LDC/GDC

[Iain Buclaw]

On 8 April 2013 14:32, David Nadlinger <see at klickverbot.at> wrote:

> On Monday, 8 April 2013 at 12:37:48 UTC, Manu wrote:
>
>> On 8 April 2013 21:46, Iain Buclaw <ibuclaw at ubuntu.com> wrote:
>>
>>> Only builtins are pure in the sense of 'C'.  Even functions considered
>>> PUREstrong by the frontend may update an internal state, so the rules
>>> just
>>> don't apply.  Except for maybe global functions...   In any case, the
>>> only
>>> benefit you can reap from 'D pure' functions are that they are more
>>> likely
>>> to be const-folded / inlined.
>>>
>>>
>> Oh my god... ..... this is the most upsetting thing I've heard all day! :(
>> No really, I have been SOOOO excited for so long about this optimisation
>> potential in D!
>> There's gotta be something that can be done! >_<
>>
>> Does the front end know if the function actually DOES assign to any state?
>> The compiler could easily work that out, and in the event it doesn't
>> actually perform any such assignment, it could be marked pure for reals...
>>
>
> Iain, are you sure about that? (No offense, but you have been wrong about
> what GCC can/can't do in the past. :P) Could you maybe elaborate a bit and
> present a counterexample? It might also be a question of how the »as-if«
> rule is really defined for pure function calls.
>
> In any case, if the source is available, the LLVM optimizer is usually
> very good at figuring out »pure for reals« (inferring the LLVM 'readnone'
> attribute). Obviously, this doesn't help you when you are doing separate
> compilation, though.
>
> David
>

Sure about what?  I don't even know what you are talking about. :o)

<sic>


-- 
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/8a845f6f/attachment-0001.html>