pragma attribute syntax

[Artur Skawina]

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.

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

The "noinline", BTW, is for some reason required in both the D-pure
and GCC-pure cases for the optimization to work.

artur