[llvm-dev] [GSoC] Supporting Efficiently the Shift-vector Instructions of the Connex Vector Processor

[Roman Lebedev via llvm-dev]

On Mon, Apr 29, 2019 at 1:56 AM Alex Susu via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>    Hello, Anton,
>      I'd like to add a small reply regarding this GSoC project that I would like to mentor
> and I discussed also with Andrei.
>      A good part of our GSoC project is indeed related to this Connex back end that it's
> not yet part of the LLVM source repository - an important thing proposed in the project is
> that we plan to perform efficient realignment for this Connex vector processor.
>
>      I looked a bit in LLVM and I see that support for realignment of misaligned vector
> memory accesses is not implemented in the LoopVectorize pass (see
> lib/Transforms/Vectorize/LoadStoreVectorizer.cpp) nor in any back end (folder lib/Target).
> Please correct me if I'm wrong.
>      But realignment is an interesting technique useful for many SIMD and (wide) vector
> processors - there are still SIMD processors today that either have performance issues or
> simply can't perform misaligned accesses, and for wide vector processors with many lanes
> this problem is equally important and even more complex. People have already addressed in
> a platform-independent way realignment of misaligned vector memory accesses - see, for
> example for GCC a paper of Nuzman and Henderson ("Multi-platform Auto-vectorization", CGO
> 2006, https://www.researchgate.net/publication/4231612_Multi-platform_auto-vectorization).
>      It would be interesting to address this issue of realignment of misaligned vector
> memory accesses in LLVM - this seems to be already well supported in GCC.

>      Please note also our Connex vector processor back end has been reviewed and we should
> be accepted as experimental (also because it has a few "exotic" features) - see, if
> interested, https://reviews.llvm.org/D60052 .
I don't believe that statement to be true/faithful to the truth.
It was not reviewed as in "ready to land".
It's not quite anywhere near that state, yet anyway.

>    Best regards,
>      Alex
Roman.

> On 4/9/2019 1:38 PM, Anton Korobeynikov via llvm-dev wrote:
> > Hello Andrei,
> >
> > You proposal seems to be centered on improvements of out-of-tree
> > backend entirely and therefore is not entirely clear what are the
> > benefits of this project to the LLVM project making the project
> > slightly outside the scope of LLVM GSoC.
> >
> > Probably it would make sense to restructure the proposal in such way
> > that it would be clear how the work that is supposed to be done over
> > the summer will benefit e.g. other backends that we already having in
> > the repository. After all, the vector instructions do exist in many
> > architectures.
> >
> > On Mon, Apr 8, 2019 at 7:53 PM Andrei Popa via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> >>
> >> Hello,
> >>
> >> I am applying for Google Summer of Code with a project related to LLVM and Connex SIMD processor and I would appreciate some feedback on the proposal.
> >> The proposal can be found here:
> >> https://docs.google.com/document/d/1pBRbW8pU9GV8zWCJQrILhynNEBpGXJKtev1j7ekXfqs/edit?usp=sharing
> >>
> >> Thank you,
> >> Andrei Popa
> >>
> >> _______________________________________________
> >> 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