[cfe-dev] [RFC] A proposal for #pragma optnone
"C. Bergström"
cbergstrom at pathscale.com
Mon Apr 28 07:54:49 PDT 2014
On 04/28/14 09:43 PM, Dario Domizioli wrote:
> > Why do you want to invent a similar, but only slightly difference
> mechanism to disable optimizations?
>
> The short answer is that our underlying infrastructure in Clang/LLVM
> is different and our mechanism has to be slightly different.
>
> Essentially, 'optnone' does not in fact implement the full feature
> that "#pragma optimize" is supposed to implement.
> A way to control optimization levels per-function has been proposed
> several times in the past (see for example
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061527.html ),
> but the community has never reached a consensus on the idea; I think
> last time the problem was that there were design issues with the
> PassManager in LLVM which at the time was being redesigned (but as far
> as I know even the redesigned version does not allow per-function
> control on optimizations). The only consensus that was reached was to
> implement a function attribute to disable local optimizations for this
> specific use case - i.e. 'optnone'.
This all derives from my personal opinion and biases - I'd rather see a
subset of an existing pragma supported and then build on that
incrementally rather than yet another pragma... I see multiple downsides
and no benefit to this approach compared to reusing what's already being
"abused".
I don't want to kick old threads or block your proposal - I just hope
you adjust it to take advantage of existing syntax..
1) Less things to document and in theory easier for users to take
advantage of
2) Less divergent from other popular compilers
3) Allows a path for incrementally improving as consensus can be reached
or blockers (PassManager) can be "fixed"
--------
For #pragma optimize - could sema accept 0 and warn/error on everything
not supported? (Would this be the same thing?)
More information about the cfe-dev
mailing list