Re: [cc65] inlining details

From: Ullrich von Bassewitz <uz1musoftware.de>
Date: 2012-02-21 22:11:34
Hi!

On Tue, Feb 21, 2012 at 02:28:51AM +0100, Groepaz wrote:
> for -Oi the docs say "Using -Oi, the code generator will inline some code
> where otherwise a runtime functions would have been called" - does that mean
> the respective functions are all from libsrc/runtime ? (so when i dont touch
> any of these, i am safe with this option?)

Yes. "-Oi" is actually a shortcut for "-O --codesize 200" which tells the
compiler that when inlining, the a growth of a specific code piece by a factor
of 2 is acceptable.

> then for -Os it says "Using -Os will force the compiler to inline some known
> functions from the C library like strlen." - is there a full list somewhere?

Possibly inlined functions are memcpy, memset, strcmp, strcpy and strlen. The
stdfunc.c module contains this list. These functions are only inlined if -Os
is given. The compiler may also change the functions instead of inlining them.
For example

        memset (ptr, 0, sizeof (*ptr));

is replaced by a call to _bzero.

In addition, _bzero is inlined even if just -O is given. This is not as bad as
it sounds since calls to _bzero (not bzero) are usually always compiler
generated by replacing calls to memset.

> (it would also be interesting to somehow have more finegrained control over
> this, eg for me it would be useful to inline strXXX functions, but not memXXX
> functions)

I don't know if this is a good idea. Your code shouldn't depend on inlining
standard functions. If you replace the standard functions with your own, but
don't change the semantics, nothing bad should happen. If you change the
semantics, then you should probably give them another name.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Tue Feb 21 22:11:49 2012

This archive was generated by hypermail 2.1.8 : 2012-02-21 22:11:52 CET