This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 01/10/2011 11:16 AM, Steve Ellcey wrote: > Here is some analysis of the failures I am getting on HP-UX, It looks > like there are some typos in mix2_even, mix2_odd, and fmix_lr where you > used %r0 (or %F0) as a input instead of %r2 (or %F2). Oops. Fixed locally. > Also, in vec_interleave_lowv4hi and vec_interleave_highv4h you switch > from unpack2.l to unpack2.h (and visa versa) in addition to swapping the > arguments for TARGET_BIG_ENDIAN but this is giving me the wrong answer > on gcc.dg/vect/vect-9.c (and probably others). I think we want to use > the same unpack2 instruction for big endian and little endian and only > swap the inputs. Does that sound right to you? It gives me the right > answer on vect-9.c. No, it doesn't sound right. Let's consider the pictures in Fig 2-45: BE gr2=[0,1,2,3] gr3=[4,5,6,7] LE gr2=[7,6,5,4] gr3=[3,2,1,0] BE unpack2.h gr1=[0,4,1,5] LE unpack2.l gr1=[5,1,4,0] That's exactly the operation we want from vec_interleave_lowv4hi. Please try the attached. It only swaps the order of arguments as you suggest, not the opcodes as I suggest. The expected output is [tonic:~] ./a.out [ 0 1 2 3 ] [ 4 5 6 7 ] [ 2 6 3 7 ] [ 0 4 1 5 ] r~
Attachment:
z.c
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |