Core Development Tools/Discussion/General/optimization : # a C file within a C file : compiler question/List of Posts
 
Forum Topic - optimization : # a C file within a C file : compiler question:
   
Update
Preeti Sharma
12/04/2007 5:45 AM
post3283
optimization : # a C file within a C file : compiler question   
I need to understand how the compiler treats a C file #included inside of another C file.
Why does this result in Optimized code or does it ? 

Thanks 

Preeti.
Aleksandar Ristovski(deleted)
12/04/2007 9:32 AM
post3292
RE: optimization : # a C file within a C file : compiler question   
C compiler gets preprocessed file from preprocessor. Preprocessor will
insert the #include file into the intermediate file that is fed to the
compiler. Therefore, when you include a .c file in another .c file, it gets
"inserted" into your compiled .c file.

This is a process that happens before compilation and therefore has no
effect on optimizations. 

> -----Original Message-----
> From: Preeti Sharma [mailto:presharm@cisco.com]
> Sent: December 4, 2007 5:45 AM
> To: general-toolchain
> Subject: optimization : # a C file within a C file : compiler question
> 
> I need to understand how the compiler treats a C file #included inside of
> another C file.
> Why does this result in Optimized code or does it ?
> 
> Thanks
> 
> Preeti.
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post3283
Stephane Boucher
12/04/2007 9:58 AM
post3298
RE: optimization : # a C file within a C file : compiler question   
On Tue, 2007-12-04 at 09:32 -0500, Aleksandar Ristovski wrote:

> This is a process that happens before compilation and therefore has no
> effect on optimizations. 

Well, partly true.  The compiler cannot optimize accross object files.
Whereas it can optimize within an object file.  So, if you:

cat *.c >big.c

and compile big.c, then you may get more optimized code than if you
compile all the .c files seperately.
Ryan Mansfield(deleted)
12/04/2007 10:31 AM
post3306
Re: RE: optimization : # a C file within a C file : compiler question   
> Whereas it can optimize within an object file.  So, if you:
> 
> cat *.c >big.c
> 
> and compile big.c, then you may get more optimized code than if you
> compile all the .c files seperately.

gcc 4.x driver has a -combine option to do just that.

Regards,

Ryan Mansfield
Preeti Sharma
12/04/2007 2:26 PM
post3312
Re: RE: optimization : # a C file within a C file : compiler question   
Thanks for the details ...

I have seen that when such files (the C files that are included within another C file) are compiled with optimization -
O3 ; I do not see a bt of the functions in included C file ....

What exactly is happening there ? 

Thanks 

Preeti
Ryan Mansfield(deleted)
12/04/2007 2:46 PM
post3313
Re: RE: optimization : # a C file within a C file : compiler question   
> Thanks for the details ...
> 
> I have seen that when such files (the C files that are included within another
>  C file) are compiled with optimization -O3 ; I do not see a bt of the 
> functions in included C file ....
> 
> What exactly is happening there ? 

As Alek explained, the #included c file gets preprocessed into one translation unit which is then compiled. This means 
the #include'd C file is compiled with the same options as the file that includes it. 

Regards,

Ryan Mansfield
Preeti Sharma
12/04/2007 3:11 PM
post3314
Re: RE: optimization : # a C file within a C file : compiler question   
Yes I understand that but that should still allow me to see a bt. If within a <big.c> file I have f1() and f2() one 
calling the other; I should see them in the bt.
irrespective of which C file they belonged to when they were compiled ...

Thanks ...
Ryan Mansfield(deleted)
12/04/2007 3:19 PM
post3315
Re: RE: optimization : # a C file within a C file : compiler question   
> Yes I understand that but that should still allow me to see a bt. If within a <big.c>
>  file I have f1() and f2() one calling the other; I should see them in the bt.
> 
> irrespective of which C file they belonged to when they were compiled ...

If you are compiling everything with -O3, then the functions are probably being inlined which is why they do not appear 
in the backtrace.

Regards,

Ryan Mansfield
Preeti Sharma
12/04/2007 3:43 PM
post3317
Re: RE: optimization : # a C file within a C file : compiler question   
True that is what I suspect too but why are they being inlined if "I do not say inline " and all the preprocessor does 
is create a <big.c> from 2 C files ...

Does that mean that all the functions in the included C file are implicitly inlined ...

Thanks 

Preeti.
Ryan Mansfield(deleted)
12/04/2007 3:56 PM
post3320
Re: RE: optimization : # a C file within a C file : compiler question   
> True that is what I suspect too but why are they being inlined if "I do not 
> say inline " and all the preprocessor does is create a <big.c> from 2 C files ...
> 
> Does that mean that all the functions in the included C file are implicitly 
> inlined ...

Not all, but it will implicitly inline functions at -O3. Which options are you using to disable inlining? -fno-inline 
and -fno-inline-functions?

Regards,

Ryan Mansfield
Stephane Boucher
12/04/2007 4:02 PM
post3322
Re: RE: optimization : # a C file within a C file : compiler ques tion   
On Tue, 2007-12-04 at 15:43 -0500, Preeti Sharma wrote:

> Does that mean that all the functions in the included C file are
> implicitly inlined ...

See:

http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html#Optimize-Options

-finline-functions
        Integrate all simple functions into their callers. The compiler
        heuristically decides which functions are simple enough to be
        worth integrating in this way. 
        
        If all calls to a given function are integrated, and the
        function is declared static, then the function is normally not
        output as assembler code in its own right. 
        
        Enabled at level -O3.
Preeti Sharma
12/04/2007 4:39 PM
post3327
Re: RE: optimization : # a C file within a C file : compiler ques   
hmm ok so not inly __inline__ functions but other functions "deemed simple" by the compiler can be inlined too ...

So to summarize:  when I say  #include a C file; since both the functions are now in the same <big.c> file the compiler 
can take the liberty to "inline" one into the other while it might be unable to do so if they reside in different C 
files ...

Thanks 

Preeti.
Rennie Allen
01/29/2008 2:28 PM
post4649
Re: RE: optimization : # a C file within a C file : compiler ques   
> hmm ok so not inly __inline__ functions but other functions "deemed simple" by
>  the compiler can be inlined too ...
> 

The __inline__ tag is merely a hint.  It indicates that the author believes the function to be a good candidate for in-
lining.

Generally compilers treat hints from authors in much the same way that baggage handlers treat a package with the label "
fragile"; so it is quite likely that the compiler will not inline some of the functions you tagged with __inline__, and 
may, in fact, inline every function except the ones that you tagged (perhaps out of spite :-).
Colin Burgess(deleted)
12/04/2007 4:02 PM
post3323
Re: optimization : # a C file within a C file : compiler ques tion   
You can check what options are passed by adding -fverbose-asm and 
generating an assembly file.

qcc -Vgcc_ntoarmle -S -fverbose-asm foo.c

you will see that there are two directives to do with inlining -finline 
and -finline-functions

In fact, if you examine the output for O2 and O3 I believe the only 
difference is -finline-functions

Colin

Preeti Sharma wrote:
>
> True that is what I suspect too but why are they being inlined if "I 
> do not say inline " and all the preprocessor does is create a <big.c> 
> from 2 C files ...
>
> Does that mean that all the functions in the included C file are 
> implicitly inlined ...
>
> Thanks
>
> Preeti.
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post3317
>

-- 
cburgess@qnx.com

Return