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. -- Joseph S. Myers jos...@codesourcery.com
