[PATCH] Handle different mode size conversions involving vectors in convert_move (PR rtl-optimization/16104) (take 3)

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Jan 26, 2005 at 02:18:12PM -0800, Richard Henderson wrote:
> On Thu, Jan 13, 2005 at 10:23:55AM -0500, Jakub Jelinek wrote:
> > Casts from vectors to integers of the same sizes or vice versa are
> > NOP_EXPRs, so the assumption that there will be only modes
> > of the same bitsize if at least one of them is vector mode
> > after folding or tree optimizers is wrong.
> 
> No, the bug is in the folder.  Conversions of vectors to a type
> not the same size is invalid; all we implement are view conversions.
> 
> Something like the following (only lightly tested) should do it.

Thanks, sorry it took me that long to dive into it again.

That patch fixed most of the 20050316-1.c testcase, but not everything.
Particularly, test4 where fold (resp. fold_unary in HEAD) saw
(V2SI) (long long) (int), it would optimize this to (V2SI) (int)
which is wrong, as the sizes don't match.

The patch below fixes that case.  Bootstrapped/regtested on 7 arches,
ok to commit 4.0/HEAD?

The second patch is with testcases that don't seem to be related to
folding, but to reload or other parts of the compiler and fail
on some arches, particularly:
20050316-2.c -O0+ !ia64
20050316-3.c -O2 x86_64
pr16104-1.c -O1+ i386
I don't want to commit the second patch now, until the issues are resolved.

BTW, are vector casts always view conversions?  Say with
(V2SI) (V2SF) x
is this supposed to be the same as
(__extension__ (({union { V2SI v2si; V2SF v2sf; }) { .v2sf = x }).v2si)
or should the floats be rounded one by one to ints?
What the compiler does ATM and the testcases in second patch test is
that they are always view conversions (i.e. the same as going through an
union).

	Jakub

Attachment: P
Description: Text document

Attachment: Q
Description: Text document