On Feb 9, 2012, at 15:33, Joseph S. Myers wrote: > For a few, yes, inline support (such as already exists for some functions > on some targets) makes sense. But for some more complicated cases it > seems plausible that LTO information in a library might be an appropriate > way of inlining while allowing the functions to be written directly in C. > (Or they could be inline in a header provided with GCC, but that would > only help for use in C and C++ code.) But neither LTO nor header-based inlining would be compatible with LGPL, right?
>> In particular, it would not address the issue of performance. For >> that we need at least a permissive license to allow full inlining, >> but it seems unlikely to me that we'd be able to get glibc code >> under those conditions any time soon. > > Indeed, if we can't then other sources would need using for the functions. > But it seems worth explaining the issues to RMS - that is, that there is a > need for permissively licensed versions of these functions in GNU, the > question is just whether new ones are written or taken from elsewhere or > whether glibc versions can be used for some functions. I'm skeptical that talking to RMS will result in relicensing of these glibc functions. If we're writing new ones (or incorporate libraries such as fdlibm), we don't need permission. >> I'd rather start collecting suitable code in GCC now. If/when a > > Whereas I'd suggest: start collecting in a separate project and have GCC > importing from that project from the start. That seems mostly like a matter of terminology. We can declare that the new libm project currently lives in gcc/libm, has a webpage at gcc.gnu.org/wiki/LibM and uses the GCC mailinglists with [libm] in the subject. It's fine with me either way. >> libm project materializes, it can take our freely licensed code >> and integrate it. I don't see why we need to wait. > > I don't think of it as waiting - I think of it as collecting the code now, > but in an appropriate place, and written in an appropriate way (using > types such as binary32/binary64/binary128 rather than particular names > such as float/double/long double, recording assumptions such as whether > the code will work on x87 with excess precision and what it needs for > rounding modes / exceptions / subnormals support). Aim initially for GCC > use, but try to put things in a more generally usable form. Agreed, we probably should do use such types regardless of where the library resides. Note that for some functions we may want to have dozens of implementations, or rather a few implementations that can be customized in myriad ways. In all cases I would expect we would provide ways of interfacing to be at source level, or a precompiled static library with LTO bytecode, in addition to libraries using the existing libm interface. >> I think nowadays it makes as little sense to have sqrt, sin, cos, >> exp and ln and other common simple elementary functions in an >> external library, as it would be for multiplication and division to >> be there. Often we'll want to generate these functions inline taking > > I've previously suggested GNU libm (rather than glibc) as a natural master > home for the soft-fp code that does provide multiplication and division > for processors without them in hardware.... > > (Different strategies would obviously be optimal for many functions on > soft-float targets, although I doubt there's much demand for implementing > them since if you care much for floating-point performance you'll be using > a processor with hardware floating point.) The same reasoning goes here: it would be best if we have a flexible interface with the compiler, so we can for example have entry points that accept and return soft-floats in "unpacked" form. Wether performance of soft-float is important or not is debatable. -Geert
