pragma attribute syntax

[Iain Buclaw]

On 6 June 2012 17:43, Artur Skawina <art.08.09 at gmail.com> wrote:
> 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

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';