[llvm-dev] SDAG: Type legalization woes (context insensitivity)

[Craig Topper via llvm-dev]

Where's the call to SetWidenedVector coming from? I would expect your case
to go through WidenVecOp_SETCC which creates a wide setcc, but appends an
extract_subvector before returning.

~Craig

On Mon, Mar 22, 2021 at 12:52 PM Krzysztof Parzyszek <kparzysz at quicinc.com>
wrote:

> We’re hitting the first one in this function (I’m trying to get a testcase
> that would reproduce this crash):
>
>
>
> void DAGTypeLegalizer::SetWidenedVector(SDValue Op, SDValue Result) {
>
>   assert(Result.getValueType() ==
>
>          TLI.getTypeToTransformTo(*DAG.getContext(), Op.getValueType()) &&
>
>          "Invalid type for widened vector");
>
>   AnalyzeNewValue(Result);
>
>
>
>   auto &OpIdEntry = WidenedVectors[getTableId(Op)];
>
>   assert((OpIdEntry == 0) && "Node already widened!");
>
>   OpIdEntry = getTableId(Result);
>
> }
>
>
>
>
>
> Yes, v64i1 is legal, but it fails the condition
> ‘getTypeToTransformTo(v32i1) == v64i1’.
>
>
>
>
>
> --
>
> Krzysztof Parzyszek  kparzysz at quicinc.com   AI tools development
>
>
>
> *From:* Craig Topper <craig.topper at gmail.com>
> *Sent:* Monday, March 22, 2021 1:55 PM
> *To:* Krzysztof Parzyszek <kparzysz at quicinc.com>
> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* [EXT] Re: [llvm-dev] SDAG: Type legalization woes (context
> insensitivity)
>
>
>
> Is v64i1 not a legal type for Hexagon? What assertion are you hitting?
>
>
> ~Craig
>
>
>
>
>
> On Mon, Mar 22, 2021 at 11:30 AM Krzysztof Parzyszek via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Summary: some types need more contextual information to properly legalize
> than what TLI queries give.
>
> Example: consider v32i1:
> 1.  v32i1 = compare v32i32, v32i32    ; all good
> 2.  v32i1 = compare v32i16, v32i16    ; problem: v32i16 not legal, but
> v32i1 is
>
>   The type v32i1 is legal because there it can be represented in a
> register and can be a result of a legal comparison of legally-typed
> vectors.  But it can also be a result of comparing illegally-typed vectors,
> which causes a problem.
>   The type legalization first looks at the value type, sees v32i1, takes
> note that it's legal.  Then, for the second case, it will attempt to
> legalize the operand types, but that action would also cause the result
> type to change (e.g. widen everything: v32i16->v64i16, v32i1->v64i1),
> hitting an assertion.
>
> I'm seeing this issue on Hexagon, but it seems to be fairly generic in its
> nature.  Has anyone else experienced this?
>
> I want to fix this somehow.  My current idea is to simply allow a known
> legal type to be replaced with another legal type, but there may be
> different approaches, like using SDValue in the TLI.whatAbouThisType family.
>
> Does anybody have concerns, thoughts?
>
> --
> Krzysztof Parzyszek  kparzysz at quicinc.com   AI tools development
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210322/b9c5574f/attachment.html>