pragma attribute syntax

[Iain Buclaw]

On 5 June 2012 00:24, Artur Skawina <art.08.09 at gmail.com> wrote:
> On 06/04/12 23:49, Iain Buclaw wrote:
>> On 4 June 2012 21:53, Artur Skawina <art.08.09 at gmail.com> wrote:
>>> On 06/04/12 21:48, Iain Buclaw wrote:
>>>> On 4 June 2012 19:49, Artur Skawina <art.08.09 at gmail.com> wrote:
>>>>> Would it be possible to allow give the gcc attribute as a string?
>>>>> So that it would be possible to express 'pragma(attribute, align(8))' etc
>>>>>
>>>>> Because right now you can not do this:
>>>>>
>>>>>   pragma(attribute, pure)
>>>>>   pragma(attribute, const)
>>>
>>>> You can use underscores as alternate syntax:
>>>>
>>>> pragma(attribute, __pure__)
>>>> pragma(attribute, __const__)
>>>>
>>>
>>> Works, thank you.
>>>
>>> And it even does the right thing - makes the compiler correctly optimize
>>> away calls to pure functions that take const ref/pointer args, which D's
>>> "pure" does not handle yet.
>
> I should probably add that, unlike the D "pure" attribute, GCC will assume
> that you know what you're doing, so it's possible to wrongly tag a function
> as pure using this pragma.
>
>> To get the equivalent of "pure", you need to mark the function as pure
>> nothrow in D.  There is no equivalent of "const" yet, but we can
>> discuss ways to go about defining that. :)
>
> No, "pure nothrow" is unfortunately not enough; the only case where it works
> as one might expect if the function takes any pointer/ref arguments, is when
> these args are immutable.
>
> D's pure functions that do not have pointer/ref inputs should map pretty
> well do GCC "const", but from the little testing I did today, it seems
> this already works reasonably well, so the "const" attribute may not be
> needed, the compiler manages to eliminate redundant calls already.
>

With help of the hints passed to the backend, it should be able to
determine that functions  a) with no side effects and b) who's return
value is ignored - should safely discarded.


> The problematic case is something like this:
>
>   struct S {
>      int a,b;
>      int[64] c;
>      pragma(attribute, noinline, __pure__) bool f() const pure nothrow {
>         return a||b;
>      }
>   }
>
> Without the pragma the compiler will call f() twice when evaluating
>
>   S s; auto r = s.f()+s.f(); /*...use r...*/
>
> I'm told this is by design, which, if true, would prevent a lot of
> valid optimizations.
>
> The (long) story: http://d.puremagic.com/issues/show_bug.cgi?id=8185
>

I've just added a change which should give it a better mapping from
keyword to gcc attribute equivalents.

D keyword -> D frontend representation (depends on function contents
however) -> gcc matched attribute

pure                -> PUREweak   -> no vops
pure const       -> PUREconst   -> const
pure nothrow    -> PUREstrong  -> pure


This means that any pure functions should be guaranteed to be
evaluated once in the use case s.f()+s.f(); - will have a play around
with it though to check for safety / correctness.

> 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.

However, this does not currently work with members outside the current
module we are compiling for.  So the next step is to get cross-module
inlining working.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';