Re: [arm-gnu] Linker driven optimization. Possible?

[Kishore <kitts.mailinglists@xxxxxxxxx>]

On Friday 29 May 2009 10:38:47 am James Kehl wrote:
> > Now, most projects only use one of the "Adc" implementation in the
>
> entire
>
> > project. So now, under such circumstances is it really possible to
> > optimize so
> > that MaximAdc and Adc are "merged" thereby avoiding the inheritance
>
> and
>
> > the
> > virtual function call? Is this also possible if the Adc and MaximAdc
>
> are
>
> > part
> > of a static link library?
>
> There is the -combine and -fwhole-program options. I don't know how
> reliable and effective these are, esp. for bare-metal ARM C++ (which may
> be three strikes against new features, in a way).

This might help. I don't yet have code that I can test this on. I wanted to 
first know if it was all worth the transition to oo C++ code from the C code 
that i currently use. It seems that the -combine option is only available for 
C code. -fwhole-program sounds interesting except that it does not sound like 
it can be used to optimize code pulled from static libraries. Have to try it.

> They must work using
> intermediate representation to do any sort of optimization at all, so
> you won't get static link libraries; you'll more likely just get doubled
> build times.

Build time is no constraint. It never takes more than a few minutes.

> Can I suggest another idea?
>
> First, make sure MaximADC and any other ADC implementations have the
> same API. In C this would be easy; in C++, you'll have to use the same
> classname for both, and you'll probably have to use a pimpl for your
> private data (which will incur an extra lookup penalty).

pimpl?

> Compile them separately, and into different static libraries if they
> happen to use multiple files.
>
> Then, only pass the implementation you want to use to the linker:
> -lmaximadc or -ltiadc or...

This is similar to what i do currently with my C code. But as i mentioned I 
only use one of the implementations in "most" projects but there are a couple 
of them that do use more than one. In those cases i do not mind the overhead 
of virtuals as it reduces overhead in other ways.

> This might not be the textbook inheritance-based OO solution, but it's
> simple, modular, and relatively maintainable.

I am not really looking for the ideal setup. Clever methods like above are 
equally acceptable. Except that in the above method i have reached beyond the 
limitation. :(
-- 
Cheers!
Kishore