On Sun, 20 Mar 2011, Jakub Jelinek wrote: > 2011-03-20 Jakub Jelinek <ja...@redhat.com> > > PR c/48197 > * c-common.c (shorten_compare): If primopN is first sign-extended > to opN and then zero-extended to result type, set primopN to opN. > > * gcc.c-torture/execute/pr48197.c: New test.
This is OK, in that I believe it is (a) correct and (b) a sensible place in the current context to fix this to avoid problems with shorten_compare not working with mixed extensions. It's worth checking if this fixes PR 42544 as well, since that also looks like it involves mixed extensions. shorten_compare is of course a mess and could do with being moved to the middle-end (ideally gimple-fold, I think) - and with having a proper conceptual model of combinations of integer conversions rather than various ad hoc cases. (The same applies to other shortening in front ends - and to anything using get_narrower at all.) Suppose you separate out the floating-point bits so you are only dealing with sequences of integer conversions. Then any such sequence can be reduced to the following (or a subset thereof): truncate to A bits, sign-extend to B bits and zero-extend to C bits (convert to a signed A-bit type, an unsigned B-bit type and an unsigned C-bit type). I think these optimizations would be both (a) safer and (b) more likely to cover all cases if they worked by computing the values of A, B and C (and the associated inner operands that get truncated / extended), using any available range information to determine that sign-extension is actually zero-extension in some cases, and then reasoned about what the best code to generate is in terms of those values. (You can also integrate left and right shifts by constant values and bitwise AND, OR and XOR with constants into a more general version of this model - truncate, left shift, sign extend, XOR with a constant, force some bits to 0 and some bits to 1 - though I don't know how useful that would be.) -- Joseph S. Myers jos...@codesourcery.com
