On Monday, 23 November 2015 at 17:31:51 UTC, Walter Bright wrote:
The calls to _d_dynamic cast appear to be redundant - shouldn't
the value in RDX be sufficient?
This is indeed the case, but of course you need to know in which
order the compiler backend wrote the type info entries to the
tables. Maybe at the time there didn't exist an intrinsic for
that in GDC or something like that.
This is how the function looks in LDC (on OS X, but the libunwind
"client"-side code is very similar):
---
0000000100000a40 <__D5test24foo1FZv>:
100000a40: 53 push rbx
100000a41: e8 ca fe ff ff call 100000910
<__D4test3abcFZv>
100000a46: e8 d5 fe ff ff call 100000920
<__D4test3defFZv>
100000a4b: 5b pop rbx
100000a4c: e9 ef fe ff ff jmp 100000940
<__D4test3jklFZv>
100000a51: 48 89 c3 mov rbx,rax
100000a54: 83 fa 03 cmp edx,0x3
100000a57: 74 05 je 100000a5e
<__D5test24foo1FZv+0x1e>
100000a59: 83 fa 02 cmp edx,0x2
100000a5c: 75 0f jne 100000a6d
<__D5test24foo1FZv+0x2d>
100000a5e: e8 5d ff 00 00 call 1000109c0
<__d_eh_enter_catch>
100000a63: 48 8b 3b mov rdi,QWORD PTR [rbx]
100000a66: e8 c5 fe ff ff call 100000930
<__D4test3ghiFC4test2CCZv>
100000a6b: eb de jmp 100000a4b
<__D5test24foo1FZv+0xb>
100000a6d: 83 fa 01 cmp edx,0x1
100000a70: 75 10 jne 100000a82
<__D5test24foo1FZv+0x42>
100000a72: e8 49 ff 00 00 call 1000109c0
<__d_eh_enter_catch>
100000a77: e8 d4 fe ff ff call 100000950
<__D4test3mnoFZv>
100000a7c: 5b pop rbx
100000a7d: e9 be fe ff ff jmp 100000940
<__D4test3jklFZv>
100000a82: 48 89 df mov rdi,rbx
100000a85: e8 16 ff 00 00 call 1000109a0
<__d_eh_resume_unwind>
---
And why is there a 'default' call to _Unwind_Resume if RDX
isn't an expected value? Shouldn't the personality routine
simply not jump to the landing pad if none of the catch types
are satisfied?
The reason LDC emits the __d_eh_resume_unwind call all the time
is because it is needed as soon as there is a cleanup involved
anyway, and so far I was just too lazy to optimize the extra
branch away in the special case that there are no cleanups.
— David
