[PATCH] D30710: [LV] Vectorize GEPs

[Matthew Simpson via llvm-commits]

Nevermind, I think I've been able to reproduce the issue on AArch64. We had
code like the following:

%tmp0 = load i32*, i32** %tmp1, align 8
store i32 0, i32* %tmp0, align 4

and the scalars analysis was marking the load for scalarization by mistake.
I'll add an appropriate test to the patch. Thanks for reporting!

-- Matt

On Tue, Mar 28, 2017 at 11:31 AM, Matthew Simpson <mssimpso at codeaurora.org>
wrote:

> Hi Ulrich,
>
> Would you mind helping me reproduce the assertion you ran into? I haven't
> been able to trigger it yet, and I'd like to make sure it's resolved before
> recommitting the patch. Thanks!
>
> -- Matt
>
> On Fri, Mar 24, 2017 at 2:53 PM, Ulrich Weigand via Phabricator via
> llvm-commits <llvm-commits at lists.llvm.org> wrote:
>
>> uweigand added a comment.
>>
>> It looks like this commit caused a regression in the test-suite on
>> SystemZ, I now get an assertion failure:
>>
>> clang-5.0: /home/uweigand/llvm/llvm-head/lib/Transforms/Vectorize/LoopVectorize.cpp:2740:
>> llvm::Value* {anonymous}::InnerLoopVectorizer::getScalarValue(llvm::Value*,
>> unsigned int, unsigned int): Assertion `Lane > 0 ?
>> !Cost->isUniformAfterVectorization(cast<Instruction>(V), VF) : true &&
>> "Uniform values only have lane zero"' failed.
>>
>> when building MultiSource/Benchmarks/Prolangs-C/TimberWolfMC/analyze.c
>>
>>
>> Repository:
>>   rL LLVM
>>
>> https://reviews.llvm.org/D30710
>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170328/0a009c8c/attachment.html>