]> git.sur5r.net Git - cc65/commit
So far the built-in inlining of several known standard function was always (!) enable...
authorOliver Schmidt <ol.sc@web.de>
Mon, 3 Apr 2017 21:20:26 +0000 (23:20 +0200)
committerOliver Schmidt <ol.sc@web.de>
Mon, 3 Apr 2017 21:20:26 +0000 (23:20 +0200)
commit02daf9f8b5c1ae2267561ee05ce67b2d0393c12d
treee2499d5529af0c0fafe70bfbac7b32955d6a9737
parentcbb2833c01a8db64931a7e1dca80736bb9f3f858
So far the built-in inlining of several known standard function was always (!) enabled and the option -Os enabled additional, potentially unsafe inlining of some of those functions.

There were two aspects of this behavior that were considered undesirable:
- Although the safe inlining is in general desirable it should only be enabled if asked for it - like any other optimization.
- The option name -Os implies that it is a safe option, the potentially unsafe inlining should have a more explicit name.

So now:
- The option -Os enables the safe inlining.
- The new option --eagerly-inline-funcs enables the potentially unsafe inlining (including the safe inlining).

Additionally was added:
- The option --inline-stdfuncs that does like -Os enable the safe inlining but doesn't enable optimizations.
- The pragma inline-stdfuncs that works identical to --inline-stdfuncs.
- The pragma allow-eager-inline that enables the potentially unsafe inlining but doesn't include the safe inlining. That means that by itself it only marks code as safe for potentially unsafe inlining but doesn't actually enable any inlining.
doc/cc65.sgml
doc/cl65.sgml
include/ctype.h
src/cc65/compile.c
src/cc65/global.c
src/cc65/global.h
src/cc65/main.c
src/cc65/pragma.c
src/cc65/stdfunc.c