On 06/06/12 18:02, Iain Buclaw wrote: > On 6 June 2012 16:03, Artur Skawina <art.08...@gmail.com> wrote: >> Hmm, is there a way to see the purity level determined by the frontend, >> w/o doing any compiler modifications? > > Unfortunately not. I can tell you that the modification would be to > d-decls.cc:(FuncDeclaration::toSymbol) - adding a fprintf(stderr) with > the purity value - hint, it's an enum.
Thanks. So far, i've been trying not to look inside the compiler at all. ;) >>>> The "noinline", BTW, is for some reason required in both the D-pure >>>> and GCC-pure cases for the optimization to work. >>> >>> This is an optimisation I pulled from ISO C++ into gdc - that all >>> member functions defined within the body of a class (and in D, this >>> includes structs too) are to be marked inline. >> >> I know. What I'm saying is that omitting the "noinline" attribute causes >> the "pure" function, like s.f() above, to be called twice. Add the >> "noinline" back, with no other changes - and it gets called only once. >> This happens both for "strongly pure" D functions and gcc-pure-tagged >> functions. It seems that either the optimizer (CSE?) gets confused by >> the inlining or it treats the case when the function body is available >> differently. >> > > Could you provide some examples? > > I can only think of this occurring for functions that have arbituary > side effects. ie: if you insert debug printf statements into pure > functions. Yes, this was exactly what i was testing with, so that i wouldn't have to look at the generated code each time. Doing things like logging every call to a function, while still wanting it to be treated as pure for optimization purposes can sometimes make sense; it was surprising that program behavior (ie whether the impure logging functions were called or not) depended on inlining decisions. I can't right now think of a test case that does not embed non-pure code inside pure; the truly pure portions could be optimized _after_ the inlining happens, so it is hard to tell if the pure-based CSE worked or not; since in my tests the impure portions remained, I was assuming it did not. If I wanted to try your changes I would need to use the gcc4.8 based tree, right? artur
