Hi All, We are able to fix the subjected issue with the peephole patterns (target specific) in the md file (attached the patch pr54589.patch). While testing the fix ,we end up with some of the C constructs like
Testcase 1:
#include <emmintrin.h>
struct param {
int a, b, c, d;
__m128i array[256];
};
void func(struct param p, unsigned char *src, int *dst)
{
__m128i x = p.array[*src];
*dst = _mm_cvtsi128_si32(x);
}
compiles with -O2 for x86-64 and asm looks like
func:
movzbl (%rdi), %eax
addq $1, %rax
salq $4, %rax
movl 8(%rsp,%rax), %eax
movl %eax, (%rsi)
ret
Testcase 2:
#include <emmintrin.h>
struct param {
int a, b, c, d;
__m128i array[256];
};
struct param *p1;
void func(unsigned char *src, int *dst)
{
__m128i x = p1->array[*src];
*dst = _mm_cvtsi128_si32(x);
}
compiles with -O2 on x86-64 :
func:
movzbl (%rdi), %eax
addq $1, %rax
salq $4, %rax
addq p1(%rip), %rax
movl (%rax), %eax
movl %eax, (%rsi)
ret
So, we are thinking to extend our fix with few more peephole patterns
in the md file.
OR it’s better to handle all C constructs in combiner/fwprop pass
,please let us know your suggestions or comments on this ,that guides
us in the right direction.
Thank you
~Umesh
On Fri, Nov 23, 2018 at 3:56 PM Umesh Kalappa <umesh.kalap...@gmail.com> wrote:
>
> Hi Richard,
>
> for the subjected issue , we found few suggestions to handle the issue like
>
> 1. be more conservative(target specific) and defining the peephole in
> the md file to handle the patterns like add,shl and movl to "shlq and
> movl"
> 2. like you mentioned in fwprop/combiner .
>
> we would like to know your inputs /suggestions before we go ahead with
> the patch.
>
> Thank you
> ~Umesh
pr54589.patch
Description: Binary data
