Messages in this thread | | | Date | Sun, 28 Nov 1999 13:43:11 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: [patch] string.h speedup, cld-2.3.30-A1 |
| |
On Sat, 27 Nov 1999, Artur Skawina wrote:
> first, namespace polution, eg copy_struct() would be safer and less > conflict prone.
yep, agreed.
> third, gcc unconditionally generating clds everywhere is a compiler > issue, which should be fixed in compiler land. something like > -mno-implicit-clds. (working around the problem by disabling gcc > optimizations isn't an optimal solution)
i believe the 'ideal' solution would be to let users override GCC's internal memcpy/etc. functions. Right now it's about cld's. But maybe in the (not so far) future we want to use SIMD instructions to do memory copies, etc.
> as an additional datapoint - i didn't see any problems either, during > the last couple of months that i ran w/o (most of) the clds.
great, although problems in this case are never visible during normal use. This is what makes this issue tricky.
> these changes are visible to userland; either your previous > /cld-ifdef-KERNEL approach/ or simply /#ifdef-KERNEL the whole header/ > would probably be safer.
ok, agreed. Although these days anything that is using kernel headers is more or less considered buggy. glibc 2.0+ has it's own string.h.
will resend the patch with these things fixed, once the 2.3.30 NUMA/bootmem changes stabilize.
-- mingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |