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

["James Kehl" <jamesk@xxxxxxxxxxx>]

> -----Original Message-----
> From: Kishore [mailto:kitts.mailinglists@xxxxxxxxx]
> Sent: Saturday, 30 May 2009 3:22 AM
> To: arm-gnu@xxxxxxxxxxxxxxxx
> Subject: Re: [arm-gnu] Linker driven optimization. Possible?
> 
> 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.
>

Like I said, whole-program optimization/link-time optimization uses IR,
not object code; static libraries are pointless then. The compiler has
to recompile (although not reparse) everything anyway.

BTW: -ffunction-sections and --gc-sections could give you slightly
better dead-code removal, despite the static libraries.

BTW2: Sounds like --combine is being deprecated in favour of Link-Time
Optimization:
http://gcc.gnu.org/wiki/LinkTimeOptimization

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

Pointer-to-implementation (ask Google).

Because in C++, classes can be allocated on the stack, the class has to
have the same size (i.e. the same fields) across all the
implementations.

If different implementations need bigger buffers, the way to handle this
is a void *; the private implementation can allocate its extra data
dynamically, store it in that slot, and cast it back when necessary.

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

Hmm, if you don't mind clean builds, what about the pre-processor?

CFLAGS += -DDEFAULT_ADC=MaximADC

void main(int argc, char **argv) {
	DEFAULT_ADC ad(PORT);

	unsigned s = ad.read_sample(1);

	printf("%d\n", s);
}

As long as you don't ever have a function that needs to work on multiple
kinds of ADC (in the same compile), you don't need virtual methods.

If you do use virtual methods, then whole-program optimization would
either have to specialize your code (make one variant copy for each type
it gets passed) or leave the virtuals in. I think this will be such a
corner-case, and likely to cause problems with DLLs, that GCC will
always leave the virtuals in (even for a single type).

James