[cfe-dev] [RFC] A proposal for #pragma optnone
Dario Domizioli
dario.domizioli at gmail.com
Tue Apr 29 08:33:08 PDT 2014
On 29 April 2014 14:55, Renato Golin <renato.golin at linaro.org> wrote:
> On 29 April 2014 14:46, Hal Finkel <hfinkel at anl.gov> wrote:
> > But why? I don't find this gcc comparison a compelling argument. It
> seems easier to support it, and more useful, than not supporting it. Adding
> a warning does not seem more difficult than adding the error. Regardless of
> what gcc does, Clang/LLVM must have a design process that keeps modern C++
> in mind, and modern C++ includes lambda functions.
>
> C++11 constructs should use annotations, not pragmas. We should only
> implement legacy pragmas for legacy behaviour. Any new pragmas, or new
> behaviour that we add on legacy pragmas will diverge from the original
> intention and require ifdefs on user code.
>
I agree on this point about lambdas.
GCC defines pragma optimize as a "function-specific pragma" that applies an
attribute to function definitions. C++11 lambdas are not exactly functions,
they are a class type with some properties (the "closure type"), one of
which is to implicitly have an operator(). So I would not expect the pragma
to have a direct effect on lambdas because there isn't an explicit
definition of the operator(). It might have an effect for lambdas defined
within an enclosed function just as an artifact of the implementation, but
it is not specified as such.
The only documentation on the MSVC pragma says that it enables/disables
optimizations starting from the first function after it. In practice it
does not seem to affect lambdas (I've only tried a simple example in VS2012
though, I haven't done extensive testing).
I think the conservative choice of not specifying any additional behaviour
for lambdas is the safest.
Also, since the main use case is debugging, and debugging a lambda has
other problems (it is often on just one line and you can't step much into
it anyway), I don't think 'optnone' would make a big difference in that
case. Basically we aren't particularly worried about lambdas for this
feature.
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/b55a4346/attachment.html>
More information about the cfe-dev
mailing list