[PATCH] D58419: [GISel]: Allow G_EXTRACT_VEC_ELT's result to be larger the source element type

Aditya Nandakumar via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 20 15:48:13 PST 2019


aditya_nandakumar added a comment.

In D58419#1404440 <https://reviews.llvm.org/D58419#1404440>, @arsenm wrote:

> In D58419#1404416 <https://reviews.llvm.org/D58419#1404416>, @aditya_nandakumar wrote:
>
> > In D58419#1404103 <https://reviews.llvm.org/D58419#1404103>, @arsenm wrote:
> >
> > > I always thought this behavior in SelectionDAG was error prone.
> >
> >
> > Personally in an out of tree backend, I find BUILD_VEC_TRUNC to be very elegant when trying to legalize/optimize vector types whose scalar types are illegal in the architecture otherwise needing several unmerges + shifts + ands.
> >  I'm fine with adding a separate opcode (say G_EXTRACT_VECTOR_ELT_ANYEXT - suggestions accepted).
> >  We need to do something similar for INSERT_VEC_ELT which can implicitly truncate.
>
>
> One question I've been thinking about is whether implicit extension is needed for G_INSERT/G_EXTRACT. I figured extract_vector_elt/insert_vector_elt with a constant could always be implemented as a G_EXTRACT/G_INSERT.


G_EXTRACT and G_INSERT are way more powerful instructions IMO and going from EXTRACT_VEC_ELT to EXTRACT seems to adding complexity (where as I'd prefer the other way if possible as sort of a canonicalization). I'm curious to hear others thoughts on this as well.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58419/new/

https://reviews.llvm.org/D58419





More information about the llvm-commits mailing list