Am Mon, 08 Apr 2013 15:32:35 +0200 schrieb "David Nadlinger" <[email protected]>:
> On Monday, 8 April 2013 at 12:37:48 UTC, Manu wrote: > > On 8 April 2013 21:46, Iain Buclaw <[email protected]> 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.
