I posted a quick comment there + the llvm ir. It seems like something that
could be a simple SimplifyInstructions transformation.
Michael
> On Jan 1, 2018, at 6:37 PM, David Zarzycki wrote:
>
>
>
>> On Jan 1, 2018, at 18:20, John McCall wrote:
>>
>>>
>>> On Jan 1, 2018, at 5:51 PM, David
> On Jan 1, 2018, at 18:20, John McCall wrote:
>
>>
>> On Jan 1, 2018, at 5:51 PM, David Zarzycki via swift-dev
>> mailto:swift-dev@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 a
> On Jan 1, 2018, at 5:51 PM, David Zarzycki via swift-dev
> 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 r
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 lin
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 wrot
Do you have the llvm-ir handy?
> On Jan 1, 2018, at 11:30 AM, David Zarzycki via swift-dev
> 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, alth
