As discussed in https://github.com/cc65/cc65/pull/452 after my premature merge the two functions in question don't work as expected.
Additionally I adjusted several style deviations in the pull request in question.
I recently came across that the question if a driver is compatible with DOS 3.3 isn't about the fact if it actually uses IRQs but if it potentially could use IRQs as the driver kernel pulls in the IRQ handler anyway. This is especially suboptimal in the scenario of statically linked drivers where it is concpetually totally clear at link time they use IRQs or not. Apart from that it might make sense to be able to define on a per-target basis if _any_ of the drivers of a certain class uses IRQs. If that isn't the cases the driver kernel for that driver class for that target could omit IRQ handling too. I'm aware that Uz imagined drivers being loaded which weren't known when the program was linked - but I don't see this.
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.
