Comment 26 for bug 303232

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?