Originally posted by caligula
View Post
Announcement
Collapse
No announcement yet.
Torvalds Is Unconvinced By LTO'ing A Linux Kernel
Collapse
X
-
Originally posted by Brane215 View PostI've used freshest gcc I could find. Last few gcc bumps in gentoo were mine, since I couldn't wait for an official ebuild. I recompiled everything so many times.
And even with gcc-4.8.2 and freshest binutils, my list of problematic packages was quite long and not shrinking much.
Comment
-
Originally posted by curaga View PostI think you posted the list in another thread. But have you posted it to GCC bugzilla?
I didn't have the time nor knowledge for such things.
And have I just showed them whole package in the report, what good would that do ? They must have known things aren't 100% peachy since so many packages failed.
And without doing the journey myself I'd just report what they already know - not all packages compile with LTO. And list of those was not shrinking, so they obviously haven't been investing work into this directly and one or a few more package names wouldn't mean a thing.
Comment
-
Having such a list publicly documented would help a lot of people: users to avoid using LTO on those, devs to focus on those. You yourself complained about lack of documentation on LTO.
If not a bug, then a gcc wiki page "Problematic packages with LTO" or such.
Comment
-
Originally posted by curaga View PostHaving such a list publicly documented would help a lot of people: users to avoid using LTO on those, devs to focus on those. You yourself complained about lack of documentation on LTO.
If not a bug, then a gcc wiki page "Problematic packages with LTO" or such.
Besides, this has made me reGoogle sh*t about LTO.
So it sent me back to "GCC Internals Manual", which I either didn't see before or it was too high for me and my brain perceived it as white noise.
Be it as it may, now I can kind of follow it. And it deals with LTO and -fwhopr etc.
I'll try to read through it and see if I can contibute in more useful way after that.
Reading that stuff gives me headaches, but it sure beats long nights guessing my way around without any documentation...
Comment
-
Originally posted by erendorn View PostFTFY.
One can care about linux and still not care about what you specifically care.
Comment
-
Originally posted by ryao View PostIt turns out this is not strictly correct. Older Linux kernels use the ts bit on x86 to try to avoid reloads as much as possible:
This is related to this question. I'm not an expert on Linux device drivers or kernel modules, but I've been reading "Linux Device Drivers" [O'Reilly] by Rubini & Corbet and a number of online
It is still basically what I described earlier though. The kernel simply does not need floating point arithmetic. Sometimes, vector instructions are useful, but in those times, we use critical sections. Anyway, few kernel developers ever use these functions.
one being just that, that its behavior is dependent on some flags (and they are cpu wide)
check out http://softpixel.com/~cwright/programming/simd/sse.php , the mxcsr register is for sse (x87 has even more stuff)
Comment
-
Originally posted by gens View Postyes, floating point is banned from the kernel for a couple reason
one being just that, that its behavior is dependent on some flags (and they are cpu wide)
check out http://softpixel.com/~cwright/programming/simd/sse.php , the mxcsr register is for sse (x87 has even more stuff)
http://wiki.osdev.org/SSE better explains what needs to be done
also i'm not 100% about how userspace floating point is handled, never had problems with it (tbh never needed to change the state, so..)
Comment
Comment