Re: [PATCH] Constant fold VIEW_CONVERT_EXPR

[Roger Sayle <roger at eyesopen dot com>]

On Wed, 4 Jan 2006, Richard Henderson wrote:
> On Tue, Jan 03, 2006 at 12:11:09AM -0700, Roger Sayle wrote:
> > + encode_view_convert_expr (unsigned char *ptr, tree expr)
>
> Why are complex and vectors handled in fold_view_convert_expr instead
> of here?

Complex and vector types are composite types made up of either
INTEGER_CSTs or REAL_CSTs.  These two subroutines are used to work
out how to pack the primitives into and out of buffers, and are
then resused for each element/component of the vectors and complex
numbers handled at the higher level.

Basically, this code has to be performed multiple times for each
element/component, so it makes sense to move it into separate
routines.

> > + 	  *ptr++ = (unsigned char) (TREE_INT_CST_LOW (expr) >> i);
> > + 	else if (i < 2 * HOST_BITS_PER_WIDE_INT)
> > + 	  *ptr++ = (unsigned char) (TREE_INT_CST_HIGH (expr)
> > + 				    >> (i - HOST_BITS_PER_WIDE_INT));
> > + 	/* It shouldn't matter what's done here, so fill with zero.  */
>
> I think its clearer if you always lay down and read data in the buffer
> in the target byte ordering.  At present you're doing double big-endian
> correction in the vector and fp code.  I think that's a recipe for mistakes.

This code is a fairly accurate of reproduction of the tried and tested
code in simplify-rtx.c:simplify_immed_subreg which has been extensively
tested on numerous platforms.  I'd be mad to attempt to write this sort
of thing from scratch, so I simply mirrored the simplify_immed_subreg
algorithms/strategy which maintains elements in a curious mix of target
orders.

Is there any benefit to keeping this stuff in buffers in target memory
order, if the current implementation works?  My concern is that the
more divergence we have between this code and simplify_immed_subreg
the harder it will be to keep fixes in sync between both.  It's a pity
that RTL and TREEs are already significantly different representations.
So extending these routines to handle STRING_CST may only be possibe
at the tree-level.

Perhaps the original author of simplify_immed_subreg could comment?

Roger
--