This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] remove nested function hack_digit

> Are you asking about the results from my particular compiler  (GCC
> 4.8.2) or in theoretical sense?

When we're concerned with generated code quality, in general it is
sufficient to demonstrate the effects just with the most-recent or a
pretty-recent GCC version.  4.8.2 is a fine reference version today.

> It doesn't mean the new code is worse or better.

What you showed does indeed mean that the new code is worse: more code to
do the same thing.  You did not show the code of hack_digit itself.  It's
possible that things improved inside the function such that the total
effect of your change is in fact an improvement or a wash, but you have to
actually analyze all the code and make a real judgment to say one or the

> There is no miracle in the nested function call,
> you still need to pass all the parameters and this is just done with a
> different calling convention.

This is not really true, or at least presented in a rather misleading way.
A call to a nested function does not pass "all the parameters" at all.
Semantically, you could say that it "passes" them all by reference.  But
what it actually does is pass a single pointer parameter (the static chain)
that is used inside the nested function for indirect access to the
containing function's local variables.  So the closest approximation of
what the existing code is doing is to put all the referenced parent locals
together into a local struct and pass a pointer to that.

In this particular case, that might be worth doing or it might be just as
good (or better) from a source maintenance perspective and/or a generated
code quality perspective to pass individual variables by reference as your
last patch does.  The onus is on you to propose a particular change,
demonstrate with thorough analysis that it improves or at least does not
harm generated code quality, and make the aesthetic case that improves or
does not substantially harm source maintenance.

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