On 6 June 2012 17:43, Artur Skawina <art.08...@gmail.com> wrote: > 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
Yeah, I go off snapshots rather than getting the source off svn or git (takes far too long). ie: ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/snapshots/LATEST-4.8/ -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
