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

[Robinson, Paul]

> From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] 
> On Behalf Of Chandler Carruth
>
> Setting aside the reasonable concerns over naming...
>
> On Mon, Apr 28, 2014 at 6:06 AM, Dario Domizioli <dario.domizioli at gmail.com> wrote:
> > Proposals like this one have not received much attention in
> > the past, but we are still keen to work with the community
> > on this.
>
> This doesn't seem accurate.
>
> When the optnone stuff was first discussed, the use of a pragma 
> *was* discussed, and there were arguments against it because
> the semantics are highly confusing: it only has effect on the 
> function definitions which are started after the pragma. This is 
> confusing as you might start the pragma *inside* a function
> definition. Such a pragma might even have semantic impact by
> disabling optimizations within the body of lambda, but *not* 
> within any surrounding expressions.

You seem to be objecting to a different proposal.

If you read Dario's proposal, you saw that putting the pragma
inside a function body is specifically prohibited.  The effect
applies to entire functions, not piecemeal within a function.

The pragma implements "apply attribute optnone to all function
definitions from here on" until the pragma gets turned off again.
How is that confusing?

>
> Personally, I find the semantics of such a pragma extremely
> confusing. I would never advocate the use of such a pragma,
> instead I would strongly advocate *against* its use in
> literally all circumstances. It is hard to support including
> it in Clang given that.

I wouldn't expect you to support something you find so confusing,
no. :-) Fortunately we are proposing something else.

>
> On the flip side, we have a function attribute which has a
> reasonable semantic model and addresses the use case originally
> posited.

It addresses certain use cases, but not others.

One significant use case is bisecting on a buggy function. This
is obviously tedious and painful if you're having to add and
remove function attributes from piles of functions, in order to
iterate down to the problem function.  Doing the same iteration
where you just move one pragma around is obviously faster and
way more convenient.  Our users are very grudgingly using the
attribute for this process (because they have little choice)
but are clamoring for a pragma.

>
> So I don't think that this is something which has been left unattended.
> I think it was attended, 

I personally remember ridiculous numbers of unanswered pings,
but whatever.  Water under the bridge.

> and in the discussion that led to optnone, the
> approach was not pursued and instead a different one was.
> -Chandler

Because we wanted something that was minimally helpful to our users
to be acceptable at all, upstream. Given your adamant objections at
the time, we backed off from the pragma and went with the attribute,
a solution you said you could support.  However, our users insist on
something simpler, i.e. a pragma that works like the pragmas that are
supported by a number of other widely used compilers.  It's a whole 
lot easier to bisect when you're only moving one line around than 
to be adding and removing attributes from piles of functions.

So, it's syntactic sugar on top of the internal implementation
mechanism, which we're not changing.
--paulr