This is the mail archive of the
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
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()
> 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
I'm not sure I understand your last point about changing macros to
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 &
I think we should just use the macro def and blow away hash() altogether.
What do you think?
- Jimmy Guo, firstname.lastname@example.org