This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: (patch) hpjyg09: bcache optimizations
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: (patch) hpjyg09: bcache optimizations
- From: Jimmy Guo <guo at cup dot hp dot com>
- Date: Thu, 4 Nov 1999 15:54:37 -0800 (PST)
- cc: gdb-patches at sourceware dot cygnus dot com
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