[PATCH] D53629: [GlobalISel] Restrict G_MERGE_VALUES capability and replace with new opcodes

Daniel Sanders via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 6 17:53:47 PST 2018


dsanders added inline comments.


================
Comment at: lib/Target/AArch64/AArch64LegalizerInfo.cpp:400-403
+      .unsupportedIf([=](const LegalityQuery &Query) {
+        const LLT &VecTy = Query.Types[0];
+        return VecTy.getElementType() != Query.Types[1];
+      })
----------------
aemerson wrote:
> dsanders wrote:
> > This can be in a follow-up patch if you prefer but I don't think these cases should be unsupported. That's really for things that are meaningless or impossible for anyone to legalize. I think we ought to legalize it even if we fewerElements all the way down to scalars.
> > 
> > Ideally, we'd have something along the lines of:
> >   .unsupportedIf([=](const LegalityQuery &Query) {
> >         // NumOperands doesn't exist right now. We should add it as it's important for variable_ops
> >         // legalization
> >         return !Query.Types[0].isVector() || !Query.Types[1].isScalar() ||
> >                Query.NumOperands != VecTy.getNumElements() + 1;
> >       })
> >   .legalFor({{v4s32, s32}, {v2s64, s64}})
> >   .clampNumElements(0, s32, v4s32, v4s32)
> >   .clampNumElements(0, s64, v2s64, v2s64)
> >   .maxNumElements(0, 1)
> >   // It's not entirely obvious what we should do with overly large scalars.
> >   // Here I've assumed we keep the SelectionDAG
> >   // semantics of BUILD_VECTOR and allow an implicit truncation
> >   .legalIf([=](const LegalityQuery &Query) {
> >         return Query.Types[0].getScalarSizeInBits() < Query.Types[1].getSizeInBits();
> >       })
> >   // At this point we only have to deal with {v4s32, <s32}, {v2s64, <s64}
> >   // I'd suggest adding this one to the library as .minScalarSameAs(1, 0) or similar
> >   .widenScalarIf([=](const LegalityQuery &Query) {
> >         return Query.Types[0].getScalarSizeInBits() > Query.Types[1].getSizeInBits();
> >       },
> >       [=](const LegalityQuery &Query) {
> >         return std::make_pair(1, Query.Types[0].getElementType());
> >       } )
> > 
> I'm leaning towards disallowing the implicit truncation for G_BUILD_VECTOR operands. Reason being that I don't think it's that useful, but I'm open to arguments for allowing it. If we disallow that, the rule is redundant as that case will be illegal coming into the legalizer.
> 
> Thinking more long term, is there any reason we need to have explicitly unsupported cases? Either they are illegal and should be caught by the verifier/never produced, or in cases where we have targets that have implemented only GISel and thus cannot fall back, there is no way to recover from a legalization failure. It's essentially the same as llvm_unreachable(). I guess it might be useful as way to run the legalizer as a verifier pass to check nothing unexpected happened.
> Thinking more long term, is there any reason we need to have explicitly unsupported cases? Either they are illegal and should be caught by the
> verifier/never produced, or in cases where we have targets that have implemented only GISel and thus cannot fall back, there is no way to recover
> from a legalization failure. It's essentially the same as llvm_unreachable(). I guess it might be useful as way to run the legalizer as a verifier pass to
> check nothing unexpected happened.

It could be an asserts-only thing. It's easier to debug if we catch a bad input or legalization step the moment it happens.


Repository:
  rL LLVM

https://reviews.llvm.org/D53629





More information about the llvm-commits mailing list