> >and thus we will hapilly merge types with different TYPE_ALIGN.
> >Should func_checker::types_compatible be extended to compare these?
> >Clearly TYPE_ALIGN matters for vectorizer and other plaes...
>
> But it matters on MEM_REFs only, and you can't use canonical types for that.
> And we don't. Tree merging correctly takes TYPE_ALING into account.
Yep, I wonder about ICF that will match the different MEM_REFs based on useless
type conversion assumptions. In fact here is a wrong code testcase:
$ more t.c
struct a
{
int a[100000];
}
__attribute__ ((aligned (32)));
struct b
{
int a[100000];
};
t2(struct a *a)
{
int i;
for (i=0;i<100000;i++)
a->a[i]++;
}
t(struct b *a)
{
int i;
for (i=0;i<100000;i++)
a->a[i]++;
}
$ ./xgcc -B ./ -O3 t.c -flto -c -fno-inline
t.c:10:1: warning: return type defaults to �int� [-Wimplicit-int]
t2(struct a *a)
^
t.c:16:1: warning: return type defaults to �int� [-Wimplicit-int]
t(struct b *a)
^
$ ./xgcc -B ./ -O3 t.o -flto -r -nostdlib
$ objdump a.out -d
a.out: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <t2>:
0: 48 8d 87 80 1a 06 00 lea 0x61a80(%rdi),%rax
7: 66 0f 6f 0d 00 00 00 movdqa 0x0(%rip),%xmm1 # f <t2+0xf>
e: 00
f: 90 nop
10: 48 83 c7 10 add $0x10,%rdi
14: 66 0f 6f 47 f0 movdqa -0x10(%rdi),%xmm0
19: 66 0f fe c1 paddd %xmm1,%xmm0
1d: 0f 29 47 f0 movaps %xmm0,-0x10(%rdi)
21: 48 39 c7 cmp %rax,%rdi
24: 75 ea jne 10 <t2+0x10>
26: f3 c3 repz retq
28: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1)
2f: 00
0000000000000030 <t>:
30: e9 00 00 00 00 jmpq 35 <t+0x5>
Function t should have alignment prologue. We need to match additional MEMREF
properties I suppose, including alignment etc.
Honza
