Dave, first, thanks for your list of libs; I'd like to refine the list here. I think Matthias looked at building multiple libgcc but that didn't see to work too well; it might not be interesting either as libgcc is meant to be a software implementation and hence doesn't have code to use use a hardware FPU. Concerning libstdc++ this might be an interesting and easier target albeit I don't know how much fp math it does; it might face the same issue as libgcc though, I'm not sure.
I don't think libgnome* are going to be too interesting. I don't know how useful qt and mesa would be, I think these can be better optimized by implementing custom backends for the GPU one targets. I've seen recent activity on the beagleboard list to enable a SGX backend for Qt for instance, and I now the intrepid PowerVR/Poulsbo drivers use some new mesa path. Everything font related is likely to be very floating-point bound, so pango and freetype are high on my list. I'm a bit worried for Pango and Gtk+ as these dlopen some plugins and I don't know whether hwcap can be used there; the plugins aren't too important for most of the use of the libs though. cairo/pixman: would certainly benefit as well; I think these can be tuned to use a DSP or GPU-specific opts. libpng/libjpeg: no strong opinion. xorg: no idea what in xorg would benefit from it exactly; perhaps Xft? -- armel gcc default optimisations https://bugs.launchpad.net/bugs/303232 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
