This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: issues with inlining


On Jan  9, 2003, Carlo Wood <carlo@alinoe.com> wrote:

> To let the compiler decide is MORE can be inlined than what I already
> marked as must-be-inlined (although it doesn't do that :/).

If you expect the inline keyword to accomplish this, check your
assumptions.  That's not the meaning of `inline' in any Standard I've
ever seen.

-finline-all-functions (implied by -O3) behaves as if every single
function has been declared as inline.  If you use one of this options,
you get what you asked for.

> Of course it is best to FIRST inline and THEN optimize - but, the set
> instruction limit should be on the optimized result, not on on the
> number of instructions before optimization.

How about your contributing this time-machine algorithm you seem to
have come up with? :-)

>   Note that even with -O0 these blocks are removed... so why the
>   need to count those instruction when deciding whether or not to
>   inline the function?!

Because we don't do many optimizations on trees yet.  As we move
optimization passes from RTL to trees, before function inlining, this
should improve.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]