This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
[RFC] Problem with altivec_vmrghb pattern in altivec.md
- From: Fariborz Jahanian <fjahanian at apple dot com>
- To: gcc at gcc dot gnu dot org
- Date: Fri, 6 May 2005 18:23:03 -0700
- Subject: [RFC] Problem with altivec_vmrghb pattern in altivec.md
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;
}