On Mon, Jan 12, 2004 at 07:31:47AM -0600, Steve Lord wrote:
The other thing these macros let you do is switch between inline code
and out of
line code based on how big you want xfs to be in code size. Some of the
macros
expand to a lot of code and are actually always compiled as functions to
avoid
too much code bloat. Probably a one off decision on inline code vs function
calls should be good enough for modern machines, that mechanism was more
concerned with making xfs run on 32M memory Irix boxes. All the definitions
in xfs_macros.h control this.
Good point. Even on Opteron boxes with incredibly big caches the rule
is still approximately to out of line code that generates more than 10-20
instructions and cannot be constant optimized by the compiler.
So it would probably make sense to just move the bigger ones out of line
unconditionally and drop the macro definitions.
But yes it is a pain to read through them - and you should try writing
new ones ;-)
The scary part about moving things to inlines would be xfs's tendency to
push
gcc to its limits on ia32. This type of thing is what has caused broken code
generation in the past.
It wouldn't be any different to macros in this regard. In modern gcc
they are equivalent as seen by the backend. But I agree that moving stuff
out of line is often a good idea (Linux went too far on the
inlining of things in the past and that is now slowly getting corrected)
The question would be only what to do with the small macros, which are most
of them. I guess these could be just made inline.
Again, if there is a chance of a patch getting merged i can do it.