<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;"><br><div><div>On Jun 17, 2013, at 11:57 AM, Xinliang David Li <<a href="mailto:xinliangli@gmail.com">xinliangli@gmail.com</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;">Dropping opt level should not lead to ABI changes. Otherwise you won't<br>be able to mix-match O2 and O0 objects either.<br></div></blockquote><div><br></div>I was referring to “static functions”. Not that it happens, but something to consider.</div><div>- Fariborz</div><div><br><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;"><br>David<br><br>On Mon, Jun 17, 2013 at 10:59 AM, jahanian <<a href="mailto:fjahanian@apple.com">fjahanian@apple.com</a>> wrote:<br><blockquote type="cite">Wouldn’t implementing this proposal be a red herring? By this I mean, it is<br>possible that<br>throughout the optimization phases, there is an implied assumption that all<br>functions<br>are similarly optimized. An example would be under certain optimization<br>flag, compiler changes<br>calling convention of static functions.<br><br>- Fariborz<br><br>On Jun 17, 2013, at 8:58 AM, <a href="mailto:Andrea_DiBiagio@sn.scee.net">Andrea_DiBiagio@sn.scee.net</a> wrote:<br><br>Hi,<br><br>I previously made a proposal for adding a pragma for per-function<br>optimization level control due to a number of requests from our customers<br>(See <a href="http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958">http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958</a> for<br>the previous discussion), however the discussion was inconclusive. Some<br>of my colleagues recently had the opportunity to discuss the proposal with<br>a number of people at and before the recent Bay Area social where it was<br>generally agreed that we should resubmit a new scaled-down proposal that<br>still addresses our users' primary use-case without introducing the<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<br>the compiler to not to perform any optimizing transformations on the<br>specified function.<br><br>The use-case is to be able to selectively disable optimizations when<br>debugging a small number of functions in a compilation unit to provide an<br>-O0-like quality of debugging in cases where compiling the whole unit at<br>anything less than full optimization would make the program run too<br>slowly. A useful secondary-effect of this feature would be to allow users<br>to temporarily work-around optimization bugs in LLVM without having to<br>reduce the optimization level for the whole compilation unit, however we<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<br>be in keeping with the existing "optsize" attribute, although it could<br>equally be called "noopt" or something else entirely. It would be exposed<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<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<br>'inlinehint'. We think that it makes sense for 'optnone' to implicitly<br>imply 'noinline' (at least from a user's point of view) and therefore<br>'optnone' should be considered incompatible with 'alwaysinline' and<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<br>would be that 'alwaysinline' wouldn't appear in the IR if 'optnone' is<br>specified.<br><br>Under the assumption that 'optnone' implies 'noinline', other things that<br>should be taken into account are:<br>1) functions marked as 'optnone' should never be considered as potential<br>candidates for inlining;<br>2) the inliner shouldn't try to inline a function if the call site is in a<br>'optnone' function.<br><br>Point 1 can be easily achieved by simply pushing attribute 'noinline' on<br>the list of function attributes if 'optnone' is used.<br>point 2 however would probably require to teach the Inliner about<br>'optnone' and how to deal with it.<br><br>As in the case of 'alwaysinline' and 'inlinehint', I think 'optnone'<br>should also override 'optsize'/'minsize'.<br><br>Last (but not least), implementing 'optnone' would still require changes<br>in how optimizations are run on functions. This last part is probably the<br>hardest part since the current optimizer does not allow the level of<br>flexibility required by 'optnone'. It seems it would either require some<br>modifications to the Pass Manager or we would have to make individual<br>passes aware of the attribute. Neither of these solutions seem<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<br>solely for the use of the individual or entity to whom they are addressed.<br>If you have received this email in error please notify <a href="mailto:postmaster@scee.net">postmaster@scee.net</a><br>This footnote also confirms that this email message has been checked for<br>all known viruses.<br>Sony Computer Entertainment Europe Limited<br>Registered Office: 10 Great Marlborough Street, London W1F 7LP, United<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>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br><br><br><br>_______________________________________________<br>LLVM Developers mailing list<br>LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu<br>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</blockquote></div></blockquote></div><br></body></html>