[llvm-dev] Scalable Vector Types in IR - Next Steps?

Renato Golin via llvm-dev llvm-dev at lists.llvm.org
Tue Jul 16 07:12:05 PDT 2019


How's the Chromium build, btw?

Did you fix all remaining issues with build times?

--renato

On Tue, 16 Jul 2019 at 10:41, Graham Hunter via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hi Alex,
>
> We've only recently managed to get the core scalable vector IR type into the codebase (so it will be present in 9.0); that allows you to write IR with scalable vector types, but there's no backend able to generate code for it yet, and as you mention no support for stepvector (or vscale). Arm will start upstreaming those soon.
>
> -Graham
>
> > On 13 Jul 2019, at 14:32, Alex Susu via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> >
> >  Hello.
> >    I am very interested in adding scalable vector support in my LLVM 8.0 compiler for the Connex SIMD research processor - but the patches discussed on llvm-dev don't work well. So can you help me?
> >    The reason I need scalable vector types is our Connex SIMD/vector processor can be synthesized in different instances with different number of lanes. Using a non-scalable vector type in our Connex LLVM compiler can result in incorrect code, for example, for the following LLVM IR instruction:
> >        %res = icmp lt <8 x i16> stepvector, <8 x i16> <10, 10, 10, ..., 10>
> >      because the result should be different if we are to run this instruction for a Connex processor with 8 VS 16 lanes,
> >      but in this case with non-scalable vector type the result is a predicate vector of all true.
> >
> >    More exactly, I don't care right now that the LoopVectorize pass generates scalable vector code. What I only want right now is that I give an LLVM IR program with scalable vector code (obtained normally from the ARM SVE LLVM compiler, built from the source code https://github.com/ARM-software/LLVM-SVE)
> >      to my standard LLVM distro + scalable vector support and it is able to:
> >          - parse the .ll LLVM IR program
> >          - then generate assembly code for my Connex back end, which I plan to use exclusively a scalable vector type like <vscale x 4 x i16>.
> >
> >
> >    I applied the 3 patches discussed in http://lists.llvm.org/pipermail/llvm-dev/2019-March/130852.html (https://reviews.llvm.org/D32530, https://reviews.llvm.org /D47770, and https://reviews.llvm.org/D53137).
> >    However, it seems there are quite a few features missing from this patch to add good scalable vector support in LLVM. For example the patches do not parse the stepvector.
> >    So I had to get inspired from the lib/AsmParser and lib/IR folders from https://github.com/ARM-software/LLVM-SVE (the ARM SVE LLVM compiler) and changed the following files in my LLVM 8.0 build:
> >       llvm/lib/AsmParser/LLLexer.cpp
> >       llvm/lib/AsmParser/LLParser.cpp
> >       llvm/lib/AsmParser/LLParser.h
> >       llvm/lib/AsmParser/LLToken.h
> >       llvm/lib/IR/Instructions.cpp
> >       llvm/include/llvm/IR/Constants.h
> >       llvm/include/llvm/IR/Value.def
> >       llvm/lib/IR/Constants.cpp
> >
> >    However, things seems to be a bit more complicated - it seems I need to patch also files in the clang folder also (https://github.com/ARM-software/Clang-SVE, for example clang/lib/CodeGen/CGExpr.cpp) since I get errors like: <<tools/clang/lib/CodeGen/CGExpr.cpp:3337: clang::CodeGen::Address emitArraySubscriptGEP(clang::CodeGen::CodeGenFunction&, clang::CodeGen::Address, llvm::ArrayRef<llvm::Value*>, clang::QualType, bool, bool, clang::SourceLocation, const llvm::Twine&): Assertion `isa<llvm::ConstantInt>(idx) && cast<llvm::ConstantInt>(idx)->isZero()' failed.>>.
> >
> >    So, since I have difficulties adding good scalable vector support in LLVM 8.0 (taken from the SVN repo in Mar 2019) I'd like to ask if anybody else has tried adding good scalable vector support in LLVM recently?
> >
> >  Thank you,
> >    Alex
> >
> >
> > On 3/29/2019 6:33 PM, Sebastian Pop via llvm-dev wrote:
> >> I had a phone conversation yesterday with Graham, Francesco,
> >> and Kristof.
> >>
> >> There is one more reason to go with the native type change:
> >> ARM has already written the code with the SV types, and they
> >> have patches ready to be reviewed and integrated in LLVM.
> >>
> >> As I don't want to stand in the way of getting SVE in LLVM
> >> as soon as possible, I will also support the integration of the
> >> existing patches and I will help with the review.
> >>
> >> Sebastian
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


More information about the llvm-dev mailing list