<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 29 April 2014 12:07, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
I've done some tests on GCC with pragmas from 0 to 3 and -O0 to -O3<br>
and the results are inconsistent. The generated code is different for<br>
"pragma N" on almost all -O levels, so no one will expect consistency.<br></blockquote><div><br></div><div>This is interesting. :-)</div><div>OK, so we can be slightly different as long as in general we cover the "disable/enable optimizations" use case in some form.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">> If people think it's better to use exactly the<br>
> existing syntax, and fail to support all of what they do, that's<br>
> okay with us (if I'm remembering the internal discussions correctly).<br>
<br>
</div>That's what I expected, yes.<br>
<br>
The same reason why we didn't invent "#pragma vectorize ...", because<br>
there were others (even if disparate) that did the same thing. The<br>
consensus was to implement each specific case from different bundles<br>
(OMP, Cilk, etc) instead of creating a list of new pragmas, and I<br>
think this is what has to be done in this case, too.<br>
<br>
General rule of new pragmas: don't.<br>
<br>
General rule of existing pragmas: mirroring attributes or annotation<br>
with the same semantics.<br></blockquote><div><br></div><div><div>I see. Yes, I now remember reading the #pragma vectorize discussion some time ago.</div><div>My concern is that we still have to make clear to the user that the full feature is not supported, but we could do it in the documentation and/or with diagnostics about unsupported parts of the feature. So I would be OK with using GCC's or MSVC's syntax, and implementing the "disable optimizations" case by adding 'optnone' to the function definitions in the range covered by the pragma.</div>
<div><br></div><div>For what we can do, GCC's syntax would require us to implement a push/pop stack as well, because if we only support the "0" level then code like this would not work:</div><div> #pragma GCC optimize "0"</div>
<div> // unoptimized code</div><div> #pragma GCC optimize "2" <-- this would not restore -O2</div><div>And it would have to be rewritten as:</div><div> #pragma GCC push_options</div><div> #pragma GCC optimize "0"</div>
<div> // unoptimized code</div><div> #pragma GCC pop_options</div><div>Users will #define those lines into a macro anyway, but it might still be a difference in style.</div><div><br></div><div>If we use the MSVC syntax, instead, we can just do it with on/off semantics, which is our main use case. However the MSVC syntax is slightly more convoluted:</div>
<div> #pragma optimize ("", off)</div><div> // unoptimized code</div><div> #pragma optimize ("", on)</div><div>And we would have to emit unsupported diagnostics if that empty string "" is not empty.</div>
<div><br></div></div><div>So from our point of view, the MSVC syntax is slightly easier to implement, but we have no strong opinion. How does the community feel about the GCC syntax vs. the MSVC syntax?</div><div>Maybe the clang-cl people would actually like a contribution towards supporting more MSVC-style code?</div>
<div><br></div><div><br></div><div>As a final note, I would reiterate that the use case for this feature is not as rare as people might think.</div><div><div>The point is that for our users (i.e. computer game programmers):<br>
</div></div><div>a) their codebase is multi-platform, and they would like all platforms to support the same features, and</div><div>b) debugging sessions are happening much more often than with other kinds of software projects.</div>
<div>Debugging games is the bread-and-butter of game programmers, essentially they do it every day.</div><div>There is therefore very strong pressure for us to implement this feature, and we still think this feature might also be beneficial (or at least neutral) in general to the wider community of users.</div>
<div><br></div><div>Cheers,</div><div> Dario Domizioli</div><div> SN Systems - Sony Computer Entertainment Group</div><div><br></div></div></div></div>