<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Wouldn’t implementing this proposal be a red herring? By this I mean, it is possible that<div>throughout the optimization phases, there is an implied assumption that all functions</div><div>are similarly optimized. An example would be under certain optimization flag, compiler changes </div><div>calling convention of static functions. </div><div><br></div><div>- Fariborz</div><div><br><div><div>On Jun 17, 2013, at 8:58 AM, <a href="mailto:Andrea_DiBiagio@sn.scee.net">Andrea_DiBiagio@sn.scee.net</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Hi,<br><br>I previously made a proposal for adding a pragma for per-function<span class="Apple-converted-space"> </span><br>optimization level control due to a number of requests from our customers<span class="Apple-converted-space"> </span><br>(See<span class="Apple-converted-space"> </span><a href="http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958">http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958</a><span class="Apple-converted-space"> </span>for<span class="Apple-converted-space"> </span><br>the previous discussion), however the discussion was inconclusive. Some<span class="Apple-converted-space"> </span><br>of my colleagues recently had the opportunity to discuss the proposal with<span class="Apple-converted-space"> </span><br>a number of people at and before the recent Bay Area social where it was<span class="Apple-converted-space"> </span><br>generally agreed that we should resubmit a new scaled-down proposal that<span class="Apple-converted-space"> </span><br>still addresses our users' primary use-case without introducing the<span class="Apple-converted-space"> </span><br>complexity of full per-function optimization level control at this time.<br><br>This proposal is to create a new function-level attribute which would tell<span class="Apple-converted-space"> </span><br>the compiler to not to perform any optimizing transformations on the<span class="Apple-converted-space"> </span><br>specified function.<br><br>The use-case is to be able to selectively disable optimizations when<span class="Apple-converted-space"> </span><br>debugging a small number of functions in a compilation unit to provide an<span class="Apple-converted-space"> </span><br>-O0-like quality of debugging in cases where compiling the whole unit at<span class="Apple-converted-space"> </span><br>anything less than full optimization would make the program run too<span class="Apple-converted-space"> </span><br>slowly. A useful secondary-effect of this feature would be to allow users<span class="Apple-converted-space"> </span><br>to temporarily work-around optimization bugs in LLVM without having to<span class="Apple-converted-space"> </span><br>reduce the optimization level for the whole compilation unit, however we<span class="Apple-converted-space"> </span><br>do not consider this the most important use-case.<br><br>Our suggestion for the name for this attribute is "optnone" which seems to<span class="Apple-converted-space"> </span><br>be in keeping with the existing "optsize" attribute, although it could<span class="Apple-converted-space"> </span><br>equally be called "noopt" or something else entirely. It would be exposed<span class="Apple-converted-space"> </span><br>to Clang users through __attribute__((optnone)) or [[optnone]].<br><br>I would like to discuss this proposal with the rest of the community to<span class="Apple-converted-space"> </span><br>share opinions and have feedback on this.<br><br>===================================================<br>Interactions with the existing function attributes:<br><br>LLVM allows to decorate functions with 'noinline', alwaysinline' and<span class="Apple-converted-space"> </span><br>'inlinehint'. We think that it makes sense for 'optnone' to implicitly<span class="Apple-converted-space"> </span><br>imply 'noinline' (at least from a user's point of view) and therefore<span class="Apple-converted-space"> </span><br>'optnone' should be considered incompatible with 'alwaysinline' and<span class="Apple-converted-space"> </span><br>'inlinehint'.<br><br>Example:<br>__attribute__((optnone, always_inline))<br>void foo() { ... }<br><br>In this case we could make 'optnone' override 'alwaysinline'. The effect<span class="Apple-converted-space"> </span><br>would be that 'alwaysinline' wouldn't appear in the IR if 'optnone' is<span class="Apple-converted-space"> </span><br>specified.<br><br>Under the assumption that 'optnone' implies 'noinline', other things that<span class="Apple-converted-space"> </span><br>should be taken into account are:<br>1) functions marked as 'optnone' should never be considered as potential<span class="Apple-converted-space"> </span><br>candidates for inlining;<br>2) the inliner shouldn't try to inline a function if the call site is in a<span class="Apple-converted-space"> </span><br>'optnone' function.<br><br>Point 1 can be easily achieved by simply pushing attribute 'noinline' on<span class="Apple-converted-space"> </span><br>the list of function attributes if 'optnone' is used.<br>point 2 however would probably require to teach the Inliner about<span class="Apple-converted-space"> </span><br>'optnone' and how to deal with it.<br><br>As in the case of 'alwaysinline' and 'inlinehint', I think 'optnone'<span class="Apple-converted-space"> </span><br>should also override 'optsize'/'minsize'.<br><br>Last (but not least), implementing 'optnone' would still require changes<span class="Apple-converted-space"> </span><br>in how optimizations are run on functions. This last part is probably the<span class="Apple-converted-space"> </span><br>hardest part since the current optimizer does not allow the level of<span class="Apple-converted-space"> </span><br>flexibility required by 'optnone'. It seems it would either require some<span class="Apple-converted-space"> </span><br>modifications to the Pass Manager or we would have to make individual<span class="Apple-converted-space"> </span><br>passes aware of the attribute. Neither of these solutions seem<span class="Apple-converted-space"> </span><br>particularly attractive to me, so I'm open to any suggestions!<br><br>Thanks,<br>Andrea Di Biagio<br>SN Systems - Sony Computer Entertainment Group<br><br><br>**********************************************************************<br>This email and any files transmitted with it are confidential and intended<span class="Apple-converted-space"> </span><br>solely for the use of the individual or entity to whom they are addressed.<span class="Apple-converted-space"> </span><br>If you have received this email in error please notify<span class="Apple-converted-space"> </span><a href="mailto:postmaster@scee.net">postmaster@scee.net</a><br>This footnote also confirms that this email message has been checked for<span class="Apple-converted-space"> </span><br>all known viruses.<br>Sony Computer Entertainment Europe Limited<br>Registered Office: 10 Great Marlborough Street, London W1F 7LP, United<span class="Apple-converted-space"> </span><br>Kingdom<br>Registered in England: 3277793<br>**********************************************************************<br><br>P Please consider the environment before printing this e-mail<br>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a></div></blockquote></div><br></div></body></html>