[PATCH] D29717: [LoopVectorize] Added address space check when analysing interleaved accesses

[Matthew Simpson via llvm-commits]

I would definitely expect to have pointer types here. The SCEVs are
collected by collectConstStrideAccesses and replaceSymbolicStrideSCEV.
Maybe you've uncovered a bug there somewhere?

On Fri, Feb 17, 2017 at 3:22 AM, Karl-Johan Karlsson via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> As I wrote earlier I had to revert the change due to a buildbot error in
> clang-with-thin-lto-ubuntu build #1847 step build-stage3-compiler. I have
> tried to recreate the buildbot fault, but failed to do so.
>
> http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu
> /builds/1847/steps/build-stage3-compiler
>
> When looking at the stacktrace from the buildbot failure it seems like
> either the type of DesA.Scev or DesB.Scev is not a pointer (in
> InterleavedAccessInfo::analyzeInterleaving()). Isn't that a bit strange?
>
> Stack trace:
> ld.lld: /home/buildbot/Buildbot/Slave1a/clang-with-thin-lto-ubuntu/
> llvm.src/include/llvm/Support/Casting.h:236: typename cast_retty<X, Y
> *>::ret_type llvm::cast(Y *) [X = llvm::PointerType, Y = llvm::Type]:
> Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"'
> failed.
> #0 0x0000000000489824 PrintStackTraceSignalHandler(void*)
> (/home/buildbot/Buildbot/Slave1a/clang-with-thin-lto-ubuntu/
> install/stage2/bin/ld.lld+0x489824)
> #1 0x0000000000489b76 SignalHandler(int) (/home/buildbot/Buildbot/Slave
> 1a/clang-with-thin-lto-ubuntu/install/stage2/bin/ld.lld+0x489b76)
> #2 0x00007fda0bb58330 __restore_rt (/lib/x86_64-linux-gnu/libpthr
> ead.so.0+0x10330)
> #3 0x00007fda0ab8dc37 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x36c37)
> #4 0x00007fda0ab91028 abort (/lib/x86_64-linux-gnu/libc.so.6+0x3a028)
> #5 0x00007fda0ab86bf6 (/lib/x86_64-linux-gnu/libc.so.6+0x2fbf6)
> #6 0x00007fda0ab86ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)
> #7 0x00000000019c7d97 (anonymous namespace)::LoopVectorizationLegality::canVectorize()
> (/home/buildbot/Buildbot/Slave1a/clang-with-thin-lto-ubuntu/
> install/stage2/bin/ld.lld+0x19c7d97)
> #8 0x00000000019bc33c llvm::LoopVectorizePass::processLoop(llvm::Loop*)
> (/home/buildbot/Buildbot/Slave1a/clang-with-thin-lto-ubuntu/
> install/stage2/bin/ld.lld+0x19bc33c)
> #9 0x00000000019ca153 llvm::LoopVectorizePass::runImpl(llvm::Function&,
> llvm::ScalarEvolution&, llvm::LoopInfo&, llvm::TargetTransformInfo&,
> llvm::DominatorTree&, llvm::BlockFrequencyInfo&, llvm::TargetLibraryInfo*,
> llvm::DemandedBits&, llvm::AAResults&, llvm::AssumptionCache&,
> std::function<llvm::LoopAccessInfo const& (llvm::Loop&)>&,
> llvm::OptimizationRemarkEmitter&) (/home/buildbot/Buildbot/Slave
> 1a/clang-with-thin-lto-ubuntu/install/stage2/bin/ld.lld+0x19ca153)
>
> Should it really be necessary to add pointer checks in the address space
> check?
>
> Regards
> / Karl-Johan Karlsson
>
>
> On 2017-02-14 14:26, Karl-Johan Karlsson via Phabricator wrote:
>
>> Ka-Ka added a comment.
>>
>> I had to revert this change due to a buildbot failure. I'm trying to
>> recreate the fault locally ...
>>
>>
>> Repository:
>>   rL LLVM
>>
>> https://reviews.llvm.org/D29717
>>
>>
>>
>>
>> _______________________________________________
> 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/20170217/b764cd1e/attachment.html>