This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: (patch) hpjyg09: bcache optimizations
- To: Jimmy Guo <guo at cup dot hp dot com>
- Subject: Re: (patch) hpjyg09: bcache optimizations
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Fri, 05 Nov 1999 12:28:15 +1100
- CC: gdb-patches at sourceware dot cygnus dot com
- Organization: Cygnus Solutions
- References: <Pine.LNX.4.10.9911041529510.15357-100000@hpcll168.cup.hp.com>
Jimmy Guo wrote:
>
> 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.
BTW, how do you get a HP compiler to inline a function? Will it just do
it if -O<very-large-number> is given?
In the case of the simulators, the decision was to build a fast correct
program when built with GCC and a slower correct program when built with
other compilers.
> 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?
Yes, I know the two comments appear contradictary. I'm assuming the
macro is approved. In that case I think a single (un-debuggable?)
implementation is better than a macro and function duplicating code.
Even having a function with a macro as its body helps - at least you can
set breakpoints on that hash function and watch what is being returned.
> 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).
True. However, I believe it is more important to avoid littering C files
with further:
#if ...
one variant
#else
another variant
#endif
If we did that we need to ensure that each alternatives continued to be
compilable.
>
> > 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.
(Er, yes, sorry, my quandry isn't very clear). Some of the old GDB
macro's would do things like:
#define X(Y) (memset (&(Y), sizeof (Y), 0); (Y).A = 1; (Y).B = 2)
I'd still prefer to see retval = BCACHE_HASH (bytes, temp_count).
Unfortunatly, that can't be implemented as an ISO-C macro so it won't
happen :-)
> 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.
I think there first needs to be a technical decision made about how much
of a price we're willing to pay for performance VS maintainability. As
you can probably tell, I have a very strong preference for the latter
:-)
If the decision is to use the macro then the corresponding hash()
function should be deleted.
enjoy,
Andrew