[PATCH] Make Scalar Replacement of Aggregates use the right opcode for converting from vector-of-int to vector-of-pointer

[Tom Roeder]

Sorry, I don't follow your description; I don't know how the SROA
algorithm works on vectors, so I don't know the conditions under which
I can get SROA to convert GEP extraction over vectors to vector loads
and stores. And I haven't yet grokked the code. Under what
circumstances would SROA do these conversions?

On Thu, Sep 12, 2013 at 3:20 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Thu, Sep 12, 2013 at 2:54 PM, Tom Roeder <tmroeder at google.com> wrote:
>>
>> Hi,
>>
>> In the process of trying to compile Chromium with clang -flto -O3,
>> I've run into a crash in SROA;  the pass is trying to cast <2 x i64>
>> to <2 x %"struct.webrtc::WindowCapturer::Window"*> with a bitcast,
>> when it should be using inttoptr. I believe this patch fixes the
>> problem.
>>
>> The problem is that convertValue in lib/Transforms/Scalar/SROA.cpp is
>> being called to convert the int vector into the pointer vector, and it
>> falls through all the cases to the bitcast at the end. So, this
>> patches catches that case and outputs the correct opcode.
>>
>> However, I'm not really familiar with either the code itself or the
>> SROA algorithm, so there might be something wrong with this patch. It
>> fixes my build, and all tests pass in the test suite, but I haven't
>> yet been able to extract a minimal test case from the crash I observe
>> in the massive Chromium LTO build that I've been working on.
>>
>> I'm hoping that this description of the crash and the fix will be
>> enough for someone to point me in the right direction for creating a
>> simple test case that triggers it.
>
>
> You should be able to create a simple test by writing code that extracts
> vector elements with GEPs and getting SROA to convert them to vector loads
> and stores. Then you just want to get one of them to use pointer types
> internally and the others to use integers, forcing the value conversion.
>
> You'll likely need a corresponding change to canConvertValue to support
> vector types.
>
> You should handle this by stripping the vector-ness first, and then handling
> the element type, so that non-vector types and vector element types have the
> same code.
>
>>
>>
>> Tom
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>