pragma attribute syntax

[Artur Skawina]

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