uClibc: ARC: enable generic string implementations

With enabled generic optimized string routines we see significant improvement of some LMbench results.

For example:
===========
libc bcopy unaligned
...
8.39 - 6.76 (UCLIBC_HAS_STRING_GENERIC_OPT=no)
8.39 - 23.86 (UCLIBC_HAS_STRING_GENERIC_OPT=yes)
===========

Since I've only did measurements on ARC and it has been ebabled for ARC for years I'm sure it doesn't break anything in either during toolchian building or in run-time.

That's why I'm keeping it as arch-specific change.

Signed-off-by Alexey Brodkin <[email protected]>

Cc Thomas Petazzoni <[email protected]>

Cc Anton Kolesov <[email protected]>

Cc Peter Korsgaard <[email protected]>

---
 package/uclibc/uclibc.mk | 1 +
 1 file changed, 1 insertion(+)

package/uclibc/uclibc.mk +0 -0

index 419a4d1..3412efd 100644

Dear Alexey Brodkin,
I personally don't like to see such a change done in an architecture specific way, if the feature is not architecture specific. So we should evaluate if this works on other architectures, see what is the binary footprint for this feature, and then decide if we want to enable it by default in our uClibc configurations.

I agree that it's better to not have this kind of generic options selected by architectures.

But the point is I don't have any real hardware except ARC and ARM boards (Cubieboard2 & Wandboard Quad).

For ARC I do see improvements and still stable behavior of toolchain and target binaries.

For ARM I don't see any difference in LMbench because most if not all string routines are already implemented in assembly, sio the option in question makes no sense.

But for other architectures like BlackFin, PPC, MIPS difference could be in both performance and stability but this is something I cannot test.

So volunteers are more than welcome.

But what if nobody else cares?

Dear Alexey Brodkin,

Quoted 16 lines · Alexey Brodkin

I agree that it's better to not have this kind of generic options selected by architectures.

But the point is I don't have any real hardware except ARC and ARM boards (Cubieboard2 & Wandboard Quad).

For ARC I do see improvements and still stable behavior of toolchain and target binaries.

For ARM I don't see any difference in LMbench because most if not all string routines are already implemented in assembly, sio the option in question makes no sense.

But for other architectures like BlackFin, PPC, MIPS difference could be in both performance and stability but this is something I cannot test.

Quoted 3 lines

So volunteers are more than welcome.

But what if nobody else cares?

If nobody cares, then we just enable the option. And people will complain when/if it breaks for them.

Quoted 2 lines

If nobody cares, then we just enable the option. And people will complain when/if it breaks for them.

So should I wait for some time or it's time to send a patch that enables the option for everybody in uClibc-*.config?

Dear Alexey Brodkin,

On Wed, 12 Nov 2014 13:54:11 +0000, Alexey Brodkin wrote:

Quoted 5 lines

Quoted 2 lines

If nobody cares, then we just enable the option. And people will complain when/if it breaks for them.

So should I wait for some time or it's time to send a patch that enables the option for everybody in uClibc-*.config?

I'd say yes. The uClibc Config.in help text for this option recommends to enable it, and it defaults to y, so I think it's pretty safe.

Regarding ARC, I see that there are arch-specific optimized string functions in libc/string/arc/, written in assembly. So by enabling GENERIC_OPT, what you gained is that you have optimized versions for those functions that don't have an ARC-specific assembly implementation?