Re: hi-res profiling

Andres Kroonmaa wrote:

> This may hold only if all code is inlined. If we use call with probe type
> as argument, func has to load array pointer, mult index by struct size, and
> then reference with offset into struct.

Yes. Is what I said. The array dereference will be most optimal if the array
is defined statically (global scope), and the code is inlined..

> I wonder how does gcc compile stuff if array is across lib boundary, will
> it at all even attempt to use direct access, or will it just load pointer
> to it from some place where "relocation" has been done?
> gcc would never inline public exported funcs, and so I wonder, how it
> handles public exported arrays?

A array is an array.

A pointer to a array is a pointer.

Simple, clean. Where the array is defined does not matter, how it is defined
matters.

extern some_type array_name[];

refers to an array defined elsewhere, of unknown size.

extern some_type array_name[size];

refers to an array defined elsewhere, of known size.

extern some_type *array_name;

refers to a pointer defined elsewhere.

It does not actually matter where this "elsewhere" is. It can be in another
object file or a library. Note: These kind of data objects cannot exists in a
shared library. If they do then they will be statically linked into the
application.

Multiplication of indeses is needed if the index is not constant, such as is
the case today.

Indirect accesses via pointer is needed if the array is not statically
allocated.

> We could also pass as argument pointer to the struct of array, which could
> be calculated in macro. Would make probe code even more simple.

True. Simplifies the array indexing by making the "multiplication" constant,
calculated in the caller, but adds a little overhead in the calling procedure
instead.. (parameter needs to be passed and retreived from the stack)

Regards
Henrik
Received on Wed Oct 02 2002 - 10:03:46 MDT