[swift-dev] Weird dyn_cast code gen / performance problem

[John McCall]

> On Jan 1, 2018, at 5:51 PM, David Zarzycki via swift-dev <swift-dev at swift.org> wrote:
> 
> Hi Michael,
> 
> I reduced it down to a simple test case. I was wrong about this requiring two or more dyn_casts. This actually affects any C++ code that uses the “if (auto x = y(z))” convention. What follows is the reduction (compiled with “clang++ -O3 -c” if it matters):
> 
> // Uncomment the next line to see the expected code gen (albeit not inlined)
> //__attribute__((used,noinline))
> int *x(void *arg) {
>   return ((long long)arg & 1) ? (int *)arg : nullptr;
> }
> 
> int test(void *arg) {
>   if (auto y = x(arg))
>     return *y;
>   return 42;
> }
> 
> It seems like inlining ‘x’ causes the compiler to effectively generate the following pseudo-code:
> 
> int test(void *arg) {
>   if (arg != nullptr)
>     if (arg & 1)
>       return *arg;
>   return 42;
> }
> 
> Which is surprising in multiple ways and (as far as I can tell) difficult to workaround without lots of source churn.
> 
> Where should I file a bug?

bugs.llvm.org <http://bugs.llvm.org/> would be best.  Including both your reduced test case and the fact that it was reduced from dyn_cast patterns should make them sit up and take notice.

John.

> 
> Dave
> 
> 
>> On Jan 1, 2018, at 13:10, David Zarzycki via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> 
>> I don’t have the IR handy. You can easily generate it for yourself though. Just drop the following into any file (I use swift/lib/AST/Type.cpp) and recompile swift.
>> 
>> Decl *my_test_function(Type t) {
>>   return t->getClassOrBoundGenericClass();
>> }
>> 
>> 
>>> On Jan 1, 2018, at 12:53, Michael Gottesman <mgottesman at apple.com <mailto:mgottesman at apple.com>> wrote:
>>> 
>>> Do you have the llvm-ir handy?
>>> 
>>>> On Jan 1, 2018, at 11:30 AM, David Zarzycki via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> I noticed recently that the code gen of CanType::getClassOrBoundGenericClass() could be better and along the way I found a clang/LLVM bug. Where exactly, I do not know, although my bet is the LLVM optimizer.
>>>> 
>>>> When more than one dyn_cast() happens in a row, LLVM/clang emits redundant and pointless nullptr checks. Both Apple clang-900.0.39.2 and clang/llvm top-of-tree generate essentially the same code:
>>>> 
>>>> <+35>: movb   0x8(%rbx), %cl  ; getKind()
>>>> <+38>: testq  %rbx, %rbx      ; XXX - nullptr check after deref is pointless
>>>> <+41>: je     0x1377df6       ; <+54>
>>>> <+43>: cmpb   $0x12, %cl      ; isa<ClassType>()
>>>> <+46>: jne    0x1377df6       ; <+54>
>>>> <+48>: addq   $0x10, %rbx     ; (void*)this + offsetof(ClassType, TheDecl)
>>>> <+52>: jmp    0x1377e06       ; <+70>
>>>> <+54>: xorl   %eax, %eax      ; the default return value (nullptr)
>>>> <+56>: testq  %rbx, %rbx      ; XXX - another pointless nullptr check?
>>>> <+59>: je     0x1377e09       ; <+73>
>>>> <+61>: cmpb   $0x29, %cl      ; isa<BoundGenericClassType>()
>>>> <+64>: jne    0x1377e09       ; <+73>
>>>> <+66>: addq   $0x18, %rbx     ; (void*)this + offsetof(BoundGenericClassType, TheDecl)
>>>> <+70>: movq   (%rbx), %rax    ; load the decl pointer
>>>> <+73>: popq   %rbx
>>>> <+74>: retq   
>>>> 
>>>> I’ve tried adding different “nonnull” spellings in various parts of both Swift and LLVM’s casting machinery, but with no luck. The only thing that seems to work is to create a free function that takes a non-null “const TypeBase *” parameter and then have CanType::getClassOrBoundGenericClass() call that.
>>>> 
>>>> FWIW – I *suspect* this is because LLVM’s casting machinery internally converts traditional pointers into C++ references before ultimately calling classof(&Val).
>>>> 
>>>> Before I file a bug against clang/llvm, might I be missing something? Can anybody think of a good workaround?
>>>> 
>>>> Dave
>>>> _______________________________________________
>>>> swift-dev mailing list
>>>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
>>> 
>> 
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20180101/0974f837/attachment.html>