On Tue, 15 Jun 2010, Paulo J. Matos wrote: > This comment provides some insight on to why gcc keeps converting to > SImode. However, I think (and it is at least applicable to my case) > that it should convert to QImode and if there are no libraries, tell > the implementor of the backend to provide those functions. I can > imagine that in some archs, like mine SImode is just too big and the > convertion turns out to be a pretty bad option.
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.) -- Joseph S. Myers jos...@codesourcery.com