On Sun, Dec 5, 2010 at 10:21 PM, Joseph S. Myers <jos...@codesourcery.com> wrote: > On Sun, 5 Dec 2010, Richard Guenther wrote: > >> Ah, you're using intrinsics. I thought of re-using the saturating arithmetic >> and types we have, thus basically do >> >> size = (unsigned sat int) count * 4; >> >> and defer optimal expansion to an optab. It of course requires saturating >> arithmetic emulation for targets that don't provide an expander but would >> allow optimal expansion at least. >> >> And it'll unleash all the latent bugs we have with saturating types ... > > And I thought that defining saturated operations for normal integer types > would be better than trying to use fixed-point types on targets that don't > have an ABI for them or where they may not match the types on which you > want saturated operations. That is, I think saturated operations would be > a better internal representation at the GIMPLE level than saturated types > (this may also apply to lowering existing fixed-point saturated type > support) and then they could be expanded to various forms of RTL including > direct saturated instructions, comparisons or overflow flags checks.
True - but it's not how saturated operations are implemented in the middle-end right now. Eventually I will finish transitioning our undefined overflow scheme to that for 4.7 though ... Richard. > -- > Joseph S. Myers > jos...@codesourcery.com >
