To help LDC/GDC

[Johannes Pfau]

Am Mon, 08 Apr 2013 15:32:35 +0200
schrieb "David Nadlinger" <see at klickverbot.at>:

> 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

I guess he only meant that the pure attribute doesn't help much,
especially when compared to the GCC __pure__ C attribute. Of course the
backend might still figure out that a function is really pure if the
source code is known, but that probably also applies to functions not
marked as pure so there's not much benefit for the backend if a
function is marked pure or not.