On Sat, 2015-01-17 at 09:42 +0100, Niels Möller wrote:
I didn't like the duplication of code either. I'm not very skilled in m4, but I though that x86_64/ could include the fat variant and use the non-sse2 variant.
I think I'd prefer to do it the other way around, with memxor-1.asm and memxor-2.asm both including x86_64/memxor.asm, just defining USE_SSE2 differently. With little actual code under fat/. Do you see any problem with that approach?
No (but no idea how to implement it).
The code in fat.c is quite elaborate on the cases it handles. The more functions added the more unmanageable the code will become. Would it make sense to restrict that support to the systems where ifunc is available? Then the addition of new optimized functions becomes very simple.
I agree that as more functions are added, we need some macros for the boilerplate code. But I think that can be done without dropping support for the non-ifunc systems. Basically, use an alternative definition of your DEFINE_FAT_FUNC which defines a wrapper function and an init function, instead of a resolver function.
I realized that non-ifunc systems are desirable, or windows support goes away. I couldn't make wrapper functions using macros. What I'm thinking is a perl script which auto-generates the wrapper functions by reading fat.c and the header files. What would you think of that?
regards, Nikos