<div dir="ltr">> Why do you want to invent a similar, but only slightly difference mechanism to disable optimizations?<br><div><br></div><div>The short answer is that our underlying infrastructure in Clang/LLVM is different and our mechanism has to be slightly different.</div>

<div><br></div><div>Essentially, 'optnone' does not in fact implement the full feature that "#pragma optimize" is supposed to implement.</div><div>A way to control optimization levels per-function has been proposed several times in the past (see for example <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061527.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061527.html</a> ), 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'.</div>




<div>Therefore, providing a pragma like "#pragma gcc optimize" that however deals with only one case (i.e. optimization level zero) would cause confusion. Ideally if we want to have such pragma we should implement the full feature, but there is no consensus on that at the moment, so we have to use a different approach.</div>


<div><br></div><div>In terms of what our users would do, they already abstract this functionality behind macros, as explained in the slides I referenced earlier. The important thing for them is that the feature is range-based rather than attribute-based, so they can #define the actual syntax with macros that can be used in the same way as with the other compilers.</div>


<div><br></div><div>I agree that the best solution would be to implement the full #pragma optimize feature. We just don't want to restart the full debate (with the risk of not reaching consensus again), and we'd rather settle for the low-hanging fruit in the short term.<br>

</div>

<div>As we note in the spec, if we ever implement the full #pragma optimize in clang/LLVM then #pragma optnone will just become obsolete and deprecated. So this proposal does not hinder any future work on the full #pragma optimize feature.</div>


<div><br></div><div>Cheers,</div><div>    Dario Domizioli</div><div>    SN Systems - Sony Computer Entertainment Group</div><div><br></div><div><br></div><div><br></div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 28 April 2014 14:37, "C. Bergström" <span dir="ltr"><<a href="mailto:cbergstrom@pathscale.com" target="_blank">cbergstrom@pathscale.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/28/14 08:06 PM, Dario Domizioli wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The goal of this feature would be to behave in a similar way to "#pragma optimize off" in Visual Studio, or "#pragma GCC optimize (0)" in gcc.<br>
<br>
</blockquote>
Why do you want to invent a similar, but only slightly difference mechanism to disable optimizations? Why not adopt something which is already familiar to a user community.<br>
<br>
Alternatively - if you insist yet another pragma is necessary - could an "alias" be made so that some of the same mechanics can be leveraged to implement the duplicate behavior?<br>
<br>
My personal opinion is that the exact wording of both the gcc and msvc are more "clean" than this possibly confusing double negative..<br>
</blockquote></div><br></div>