This is the mail archive of the gcc@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]

[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;
}


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]