Project Home
Project Home
Source Code
Source Code
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - optimization : # a C file within a C file : compiler question: (14 Items)
   
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.
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
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.

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 


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
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

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 ...

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
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.
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

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. 
        
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.
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 :-).
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