I'd certainly like to see egcs improve "long long" handling, but I think
that on the x86 the problem is twofold. The long long handling is just
plain bad, and that's probably the easiest one to fix up with some md file
updates. But the worse problem is probably bad register handling in gcc,
both for normal registers and for "eflags".
For example, a lot of the long long things are really _five_ register
inputs: two source registers, two source-dest registers, and eflags to
keep track of the carry bit. That means that you have four registers (out
of eight) just for data - something that gcc isn't too good at anyway, but
you also have the added constraint that you must keep the right eflags
updates: and gcc-x86 doesn't seem to track eflags at all (it has various
"magic" eflags rules, but gcc doesn't actually seem to consider eflags to
be a real register, so it can't actually schedule any of the code very
well).
Maybe egcs is better at handling eflags on x86, but I'd really like to
think that we have a stable compiler first, rather than trusting a known
bad compiler (yes, gcc is actually known for having generated not only
slow but actually buggy code for "long long").
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu