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 <mgottes...@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@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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
>
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
