[Top] [All Lists]


To: Andi Kleen <ak@xxxxxxxxxxxxx>
From: Steve Lord <lord@xxxxxxx>
Date: Tue, 13 Jan 2004 07:40:36 -0600
Cc: Glen Overby <overby@xxxxxxx>, linux-xfs@xxxxxxxxxxx, ak@xxxxxx
In-reply-to: <20040112183604.GA45023@colin2.muc.de>
References: <20040111114500.GA4508@averell> <200401111621.i0BGLhA63464298@daisy-e236.americas.sgi.com> <20040111164549.GA45569@colin2.muc.de> <4002A1C3.8000608@xfs.org> <20040112183604.GA45023@colin2.muc.de>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
Andi Kleen wrote:
Hi Steve,

Hi Andy,

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.

I would have to leave that one to the folks still at SGI. Changing from macros to functions would look pretty odd without changing the case, and changing the case makes it a very intrusive mod. There really is an effort to keep Irix and Linux somewhat similar, but so far as I know code from outside the company has never gone back into Irix. Because of that the chances are slim.

If you want to push, and can come up with a mechanism which does not
look too intrusive, prototype it with a couple of macros and see
what people think.


<Prev in Thread] Current Thread [Next in Thread>