there a bug open for it yet?
-
-
-
It's not strictly a "bug", but a QoI issue that can cause code that "should" work at a given stack size to stack overflow, and that hurts performance in some code paths.
-
I think it's known that gcc shrinkwraps poorly, but I'm not sure if I found new things that aren't already known.
-
Failure to shrinkwrap float register save/restore is a fairly big performance flaw on archs where the fpu might be missing and the kernel is expected to trap-and-emulate. Suddenly non-float codepaths could become 10000x slower just because of the gratuitous save/restore.
End of conversation
New conversation -
-
-
OOC why does this occur? Surely with nofpu you’re using a softfloat toolchain/switches so you emulate instead of SIGILL on FP instructions?
-
The issue was found by someone wrongly using an arm*eabihf toolchain on a chip without fpu and expecting it to work as long as no float code was invoked. This is not valid usage if the ABI does not mandate real or trap-and-emulate fpu insns be available. However...
-
There are real-world archs (mips) where the normal ABI always has float registers/insns and kernel is expected to trap-and-emulate if hardware doesn't. GCC's bad hoisting (or failed shrinkwrap) here will make some code 5 orders of magnitude slower in code paths not using floats.
-
Oh, so MIPS has no softfloat? OS is always expected to do no FP and also contain emulation support? Interesting. TIL :)
-
Traditionally, even with many chips not having full or any fpu, the only ABI was hardfloat. Then OpenWRT went and did a nonstandard softfloat thing to cut down kernel size (emulation code) but added same amt of code to userspace (or much more if anything's static linked).
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.