This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: (patch) hpjyg09: bcache optimizations


Andrew,

1) Not all compilers support the inline keyword (HP C compiler for
   example), so it will be a nop change in such cases.  Therefore the
   macro def might be the only way to optimize this away.

2) The macro def is duplicating the hash() implementation.  I agree that
   one implementation is much maintainable.  While hash() could use
   BCACHE_HASH macro, what about the 1st point you made about debugging
   and use of macros?

3) In the actual use of BCACHE_HASH vs. the hash() call, yes a default
   BCACHE_HASH can be provided which calls hash().  However, this would
   introduce yet another macro wrapper (to address both 2 and 3 ... one
   for the hash implementation -- 2; another for the hash call wrapper
   using the macro implementation directly or through an actual hash()
   wrapper).

>	o	I'm in too minds over the first argument
>		(HASHVAL). I recently spent time eliminating
>		several really bad macro definitions that
>		abused the fact that they had direct access to
>		arguments - changing them to multi-arch functions
>		was, er, non-trivial.
>
>		However, in this case, the rational and use is
>		clean.

I'm not sure I understand your last point about changing macros to
multi-arch functions.

Since:
 a) the macro def is pretty much necessary to make the change
    meaningful (see 1),
 b) to have one implementation of hash and make the usage clean (see 2 &
    3),
I think we should just use the macro def and blow away hash() altogether.

What do you think?

- Jimmy Guo, guo@cup.hp.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]