[cfe-dev] [RFC] A proposal for #pragma optnone

[Dario Domizioli]

On 29 April 2014 12:07, Renato Golin <renato.golin at linaro.org> wrote:

>
> I've done some tests on GCC with pragmas from 0 to 3 and -O0 to -O3
> and the results are inconsistent. The generated code is different for
> "pragma N" on almost all -O levels, so no one will expect consistency.
>

This is interesting. :-)
OK, so we can be slightly different as long as in general we cover the
"disable/enable optimizations" use case in some form.



> >  If people think it's better to use exactly the
> > existing syntax, and fail to support all of what they do, that's
> > okay with us (if I'm remembering the internal discussions correctly).
>
> That's what I expected, yes.
>
> The same reason why we didn't invent "#pragma vectorize ...", because
> there were others (even if disparate) that did the same thing. The
> consensus was to implement each specific case from different bundles
> (OMP, Cilk, etc) instead of creating a list of new pragmas, and I
> think this is what has to be done in this case, too.
>
> General rule of new pragmas: don't.
>
> General rule of existing pragmas: mirroring attributes or annotation
> with the same semantics.
>

I see. Yes, I now remember reading the #pragma vectorize discussion some
time ago.
My concern is that we still have to make clear to the user that the full
feature is not supported, but we could do it in the documentation and/or
with diagnostics about unsupported parts of the feature. So I would be OK
with using GCC's or MSVC's syntax, and implementing the "disable
optimizations" case by adding 'optnone' to the function definitions in the
range covered by the pragma.

For what we can do, GCC's syntax would require us to implement a push/pop
stack as well, because if we only support the "0" level then code like this
would not work:
    #pragma GCC optimize "0"
    // unoptimized code
    #pragma GCC optimize "2"  <-- this would not restore -O2
And it would have to be rewritten as:
    #pragma GCC push_options
    #pragma GCC optimize "0"
    // unoptimized code
    #pragma GCC pop_options
Users will #define those lines into a macro anyway, but it might still be a
difference in style.

If we use the MSVC syntax, instead, we can just do it with on/off
semantics, which is our main use case. However the MSVC syntax is slightly
more convoluted:
    #pragma optimize ("", off)
    // unoptimized code
    #pragma optimize ("", on)
And we would have to emit unsupported diagnostics if that empty string ""
is not empty.

So from our point of view, the MSVC syntax is slightly easier to implement,
but we have no strong opinion. How does the community feel about the GCC
syntax vs. the MSVC syntax?
Maybe the clang-cl people would actually like a contribution towards
supporting more MSVC-style code?


As a final note, I would reiterate that the use case for this feature is
not as rare as people might think.
The point is that for our users (i.e. computer game programmers):
a) their codebase is multi-platform, and they would like all platforms to
support the same features, and
b) debugging sessions are happening much more often than with other kinds
of software projects.
Debugging games is the bread-and-butter of game programmers, essentially
they do it every day.
There is therefore very strong pressure for us to implement this feature,
and we still think this feature might also be beneficial (or at least
neutral) in general to the wider community of users.

Cheers,
    Dario Domizioli
    SN Systems - Sony Computer Entertainment Group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140429/47754388/attachment.html>