[llvm-dev] GISel using deprecated vector_extract for G_EXTRACT_VECTOR_ELT mapping

[Daniel Sanders via llvm-dev]

> On Dec 9, 2020, at 06:51, Björn Pettersson A via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> According to code comment the definition of vector_extract has
> been deprecated for ~5 years (at least since Dec 11, 2015).
> 
> Seems like some targets still are using it, and even the GlobalISel
> implementation is supporting this deprecated functionality by
> adding a mapping between G_EXTRACT_VECTOR_ELT and vector_extract
> in SlectionDAGCompat.td.

GlobalISel only supports them because the first targets implemented used vector_extract

> My target is not using the deprecated vector_extract, and it is using
> the preferred extractelt definition instead in tablegen patterns.
> 
> The problem is that there is no similar mapping between
> extractelt and G_EXTRACT_VECTOR_ELT.
> 
> Is it allowed to have several GINodeEquiv statements, mapping the
> same GISel instruction to different SDNodes?
> 
> (i.e. would it be wrong to also add a mapping between
> G_EXTRACT_VECTOR_ELT and extractelt)

Off-hand, I don't think there's a reason that would be a problem so long as you only have one or the other in your target. The GINodeEquiv relations are there to map operators in the rule like vector_extract/extractelt to their GISel counterparts so it can generate code in GISel terms. If you somehow have both and they have overlapping rules then it would be undefined which rule is used.

> Or should we stop using the deprecated nodes in GISel mappings?
> 
> (then I assume someone need to finalize the work of getting rid
> of vector_extract, at least in targets that support GISel, but
> after 5 years I think it is about time to either remove the
> deprecated definition or replace the "deprecated" comment with
> something that explains why we need both vector_extract and
> extractelt)
> 
> 
> PS. The above questions also apply to vector_insert vs insertelt.
> 
> /Björn
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev