Uhg, gcc is doing the idiotic llvm thing of maximally-hoisting large stack usage, and also float usage (saving call-saved float regs). This surprisingly leads to hardfloat code SIGILL'ing on nofpu machines even when the float code is never reached.
-
-
-
Replying to @cooljeanius
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.
1 reply 0 retweets 1 like -
Replying to @RichFelker @cooljeanius
I think it's known that gcc shrinkwraps poorly, but I'm not sure if I found new things that aren't already known.
2 replies 0 retweets 1 like
Replying to @RichFelker @cooljeanius
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.
3:45 PM - 7 Aug 2018
0 replies
0 retweets
1 like
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.