On Tue, Jun 15, 2010 at 10:42 AM, Joseph S. Myers <jos...@codesourcery.com> wrote: > On Tue, 15 Jun 2010, Paulo J. Matos wrote: > > For targets with 8-bit bytes and 32-bit registers (and without hardware > floating point), there is probably no point in having most conversion > functions to/from QImode or HImode separate from those to/from SImode, as > they likely wouldn't be any more efficient so would just make libgcc > larger or add unnecessary aliases. So maybe there should be a target hook > indicating the narrowest integer mode for which there are conversion > functions in libgcc, or something similar to that. (Perhaps conversions > from HImode to SFmode do make sense as separate from those from SImode to > SFmode, in that they don't need to handle rounding so could be smaller and > faster - but then you expand libgcc by having two functions instead of > one. > On 8-bit and 16-bit targets it seems more likely conversion > functions for QImode and HImode are useful, though again you are expanding > libgcc and any program that uses both those and the SImode functions.) >
I would think that the best would be to avoid implicit convertions to SFmode that might awe backend devs for 'wierd' archs like me. The target hook looks like a neat idea as it would keep current modes as they are and for those of us in these archs, when we would get undefined symbol errors for, lets say, floatunqihf, then we know that we need to provide a definition for that as libgcc does not. I don't think that libgcc should provide all possible conversions but enabling the developer to know which conversions he has to include for his particular backend seems rather important. -- PMatos
