pragma attribute syntax

Artur Skawina art.08.09 at
Wed Jun 6 09:43:47 PDT 2012

On 06/06/12 18:02, Iain Buclaw wrote:
> On 6 June 2012 16:03, Artur Skawina <art.08.09 at> 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
> - 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?


More information about the D.gnu mailing list