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

Chandler Carruth chandlerc at google.com
Mon Apr 28 13:53:31 PDT 2014


On Mon, Apr 28, 2014 at 10:54 AM, Philip Reames
<listmail at philipreames.com>wrote:

> Chandler, while I actually agree with you in principal, I think you're
> ignoring an important factor.  The pragma approach is already widely
> deployed.  If we don't support pragma usage, there's no real migration path
> for these applications.


I'm not ignoring it in this case, but this is a special and unusual case,
so it is somewhat surprising.

The fact of the matter is that existing usage of this pragma outside of
Clang and LLVM is somewhat irrelevant. There were only two proposed uses of
this pragma when it was brought up:

1) Working around a miscompile in the compiler.
2) Debugging a single function in unoptimized form while the rest of the
program was optimized.

In the first use case, there is no reason to care about existing
deployments as those are targeted at fixing a different compiler's
miscompiles.

In the second case, there is no widespread checked in usage of this pattern
because it is only used for the sake of debugging sessions.

Again, this was discussed previously. The variant on #2 which came up was a
header or macro that enabled the pragma for one TU at a time in a somewhat
programmatic way. However, the response was that it would be much better to
do this at the build system level, and there was never any real argument
against that.

In general, the use cases for this *particular* pragma seem vanishingly
small. It does not establish an ABI, provide a semantic contract, or
control diagnostics. It is not something that would be expected to be
checked into a codebase long term and work across implementations (see #1).
So I don't think the legacy application concerns apply in this case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140428/6fad8b46/attachment.html>


More information about the cfe-dev mailing list