[RFC] Problem with altivec_vmrghb pattern in altivec.md

[Fariborz Jahanian]

One of our internal apps fails due to problem in folding of vec_mergeh 
of unsigned char of zeros and ones. It produces a new vector of zeros 
followed
by ones. I traced the problem to the 3rd operand for the 
"altivec_vmrghb" pattern defined in altivec.md file. It is 255 (0xff). 
I think it
should be 21845  for unsigned chars (0x5555). With this change, 
customer code passes and merged pattern looks OK.
So far so good. But I tried the following test case (with -O2) and 
curiously enough it works OK with or *without* my change!. So, I am 
wondering if
I approached this problem correctly.
 From the code in simplify-rtx.c where value of merge of two constants 
in a VEC_MERGE rtl is computed, it seems that the correct value for 
element
selection should be 0x5555. But I am curious why changing this value 
did not make a difference in the following test case (compiled with 
-O2).

- Thanks, fariborz (fjahanian@apple.com)

#include <stdio.h>

int main (int argc, const char * argv[]) {

     vector unsigned char v_zero;
     vector unsigned char v_c1;

     v_zero   = (vector unsigned char) 
('a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p');
     v_c1   = (vector unsigned char)  
('1','2','3','4','5','6','7','8','1','2','3','4','5','6','7','8');

     vector unsigned char vResult = vec_mergeh(v_zero, v_c1);

     printf ("\t%vc\n", vResult);
     return 0;
}