Clang miscompiles crtend.

[EdSchouten]

Bugzilla Link	3709
Resolution	INVALID
Resolved on	Mar 04, 2009 14:38
Version	unspecified
OS	FreeBSD
Blocks	#4068
Attachments	Reduced testcase
CC	@asl,@efriedma-quic,@pwo

Extended Description

When compiling the attached code without any optimization on x86_64, Clang generates the following:

0000000000000000 <__do_global_ctors_aux>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: 48 83 ec 10 sub $0x10,%rsp
8: 48 8d 04 25 00 00 00 lea 0x0,%rax
f: 00
10: 48 b9 f8 ff ff ff ff mov $0xfffffffffffffff8,%rcx
17: ff ff ff
1a: 48 01 c8 add %rcx,%rax
1d: 48 89 45 f8 mov %rax,0xfffffffffffffff8(%rbp)
21: 48 8b 45 f8 mov 0xfffffffffffffff8(%rbp),%rax
25: 48 8b 00 mov (%rax),%rax
28: b9 ff ff ff ff mov $0xffffffff,%ecx
2d: 89 c9 mov %ecx,%ecx
2f: 48 39 c8 cmp %rcx,%rax
32: 74 20 je 54 <__do_global_ctors_aux+0x54>
34: 48 8b 45 f8 mov 0xfffffffffffffff8(%rbp),%rax
38: 48 8b 00 mov (%rax),%rax
3b: ff d0 callq *%eax
3d: 48 8b 45 f8 mov 0xfffffffffffffff8(%rbp),%rax
41: 48 b9 f8 ff ff ff ff mov $0xfffffffffffffff8,%rcx
48: ff ff ff
4b: 48 01 c8 add %rcx,%rax
4e: 48 89 45 f8 mov %rax,0xfffffffffffffff8(%rbp)
52: eb cd jmp 21 <__do_global_ctors_aux+0x21>
54: 48 83 c4 10 add $0x10,%rsp
58: 5d pop %rbp
59: c3 retq

If we turn on the optimizer, we get:

0000000000000000 <__do_global_ctors_aux>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: 30 c0 xor %al,%al
6: 66 data16
7: 66 data16
8: 66 data16
9: 90 nop
a: 66 data16
b: 66 data16
c: 90 nop
d: 66 data16
e: 66 data16
f: 90 nop
10: f6 d0 not %al
12: a8 01 test $0x1,%al
14: b0 00 mov $0x0,%al
16: 75 f8 jne 10 <__do_global_ctors_aux+0x10>
18: 5d pop %rbp
19: c3 retq

GCC generates the following code when using -O:

0000000000000000 <__do_global_ctors_aux>:
0: 53 push %rbx
1: 48 8b 05 00 00 00 00 mov 0(%rip),%rax # 8 <__do_global_ctors_aux+0x8>
8: 48 83 f8 ff cmp $0xffffffffffffffff,%rax
c: 74 18 je 26 <__do_global_ctors_aux+0x26>
e: bb 00 00 00 00 mov $0x0,%ebx
13: ff d0 callq *%eax
15: 48 8b 83 00 00 00 00 mov 0x0(%rbx),%rax
1c: 48 83 eb 08 sub $0x8,%rbx
20: 48 83 f8 ff cmp $0xffffffffffffffff,%rax
24: 75 ed jne 13 <__do_global_ctors_aux+0x13>
26: 5b pop %rbx
27: c3 retq

[llvmbot]

What do you think is wrong with the clang generated code (I haven't looked yet)?

[EdSchouten]

I guess because the array is intialized with zeroes, the compiler generates an infinite loop. This is not valid, because we index the array negatively.

This code is used during process shutdown to call functions registered with atexit().

[efriedma-quic]

Can you try and see if r66009 helps?

[EdSchouten]

When using revision 66017, I still get the following:

0000000000000000 <__do_global_ctors_aux>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: 30 c0 xor %al,%al
6: 66 data16
7: 66 data16
8: 66 data16
9: 90 nop
a: 66 data16
b: 66 data16
c: 90 nop
d: 66 data16
e: 66 data16
f: 90 nop
10: f6 d0 not %al
12: a8 01 test $0x1,%al
14: b0 00 mov $0x0,%al
16: 75 f8 jne 10 <__do_global_ctors_aux+0x10>
18: 5d pop %rbp
19: c3 retq

The issue is still present.

[efriedma-quic]

Ah, I see what's going on... LLVM is deciding that loads with targets before the beginning of the CTOR_END are undefined, and eliminates everything in the loop. That's normally a legitimate transform... the issue is that CTOR_END isn't a normal symbol. I'm not sure what the right fix is here.

(The relevant code is in InstCombiner::visitLoadInst.)

[EdSchouten]

Yes, exactly. :-)

[lattner]

The problem here is that CTOR_END has magic semantics that the compiler doesn't know about, and is marked static. The proper way to tell the compiler "don't touch" is to use attribute((used)), and doing so fixes the problem. Please use something like this:

static func_ptr attribute((used)) CTOR_END[1] attribute((section(".ctors"), aligned(sizeof(func_ptr)))) = { (func_ptr) 0 };

-Chris

[efriedma-quic]

The problem here is that CTOR_END has magic semantics that the compiler
doesn't know about, and is marked static. The proper way to tell the compiler
"don't touch" is to use attribute((used)), and doing so fixes the problem.

I think my explanation was slightly off; here's a somewhat more detailed explanation of what goes wrong. The function does a series of loads, starting with CTOR_END[-1]. After the global is marked as constant, instcombine sees that the global is constant and initialized to null. InstCombine assumes that a load from a null global must be null, so it concludes CTOR_END[-1] == 0.

InstCombine currently doesn't optimize CTOR_END[-1] if it isn't marked as a constant, but it seems dangerous to depend on that; does attribute((used)) have some semantics that are relevant here?

[lattner]

used will prevent it from being marked 'constant', which will prevent the load from forwarding from it.

[efriedma-quic]

used will prevent it from being marked 'constant', which will prevent the load
from forwarding from it.

Why is the optimization CTOR_END[-1] -> unreachable illegal if CTOR_END is marked used? Is that part of the semantics of "used"? Or is it just "technically legal, but breaks code"?

[lattner]

I don't think it is, I agree that used doesn't imply that, but hey we happen to not do that optimization :)