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

[Hal Finkel]

----- Original Message -----
> From: "Paul Robinson" <Paul_Robinson at playstation.sony.com>
> To: "Chandler Carruth" <chandlerc at google.com>, "Dario Domizioli" <dario.domizioli at gmail.com>
> Cc: "clang-dev Developers" <cfe-dev at cs.uiuc.edu>
> Sent: Monday, April 28, 2014 4:51:15 PM
> Subject: Re: [cfe-dev] [RFC] A proposal for #pragma optnone
> 
> > 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.

As Chandler points out, you would want to put them inside function bodies to catch lambdas. However, we should issue a warning in this case.

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

I'd like to say that I find this use case compelling, and I'm now in favor of this functionality.

 -Hal

> 
> >
> > 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
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory