[llvm-bugs] [Bug 28365] New: LLVM legalizer crashes when target legalizes some operation and LLVM legalizes some

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=28365

            Bug ID: 28365
           Summary: LLVM legalizer crashes when target legalizes some
                    operation and LLVM legalizes some
           Product: libraries
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: hisham_chow at yahoo.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 16650
  --> https://llvm.org/bugs/attachment.cgi?id=16650&action=edit
patch

For example, when target marks i8, i16 type as illegal for the target, LLVM
backend legalization kicks in and tries to promote the operation to higher
supported types using “GetPromotedInteger” in LegalizeIntegerTypes.cpp->
PromoteIntegerOperand and updates a map (PromotedIntegers[Op]) to indicate the
values promoted and to what type. But this function doesn’t handle target
intrinsics which uses these illegal types. So, when target provides hooks to
legalize the target intrinsic, target promotes the node to higher type(in this
case i32) and return the result. That code path from PromoteIntegerOperand
function returns right away without updating the map when target provides the
legalization hook:
  // See if the target wants to custom expand this node.
  if (CustomLowerNode(N, N->getValueType(ResNo), true))
    return;
So when user(standard ISD instruction, example SLL) of the target intrinsic
comes in and when LLVM tries to legalize it by calling
GetPromotedInteger->PromotedIntegers[Op], the code expecting the Op to be i16,
but target already promoted it to i32. So, the map return NULL and the code
fails/asserts
Here is a simple code snippet that expose the issue:

  %1 = tail call zeroext i16 @llvm.igil.ftous.sat(float -1.000000e+00) #2 //
target legalizes it and changes the result to i32
  %2 = shl i16 %1, 11
  %3 = zext i16 %2 to i32, !dbg !22


Looks like some of the path related to this issue is fixed in the trunk(shift
legalization case), but not all the functions that use GetPromotedInteger.
Here is an example of shift legalization fix:
#ifdef LATEST
    SDValue LHS = N->getOperand(0);
    SDValue RHS = N->getOperand(1);
      if (getTypeAction(LHS.getValueType()) ==
TargetLowering::TypePromoteInteger)
        LHS = GetPromotedInteger(LHS);
      if (getTypeAction(RHS.getValueType()) ==
TargetLowering::TypePromoteInteger)
        RHS = ZExtPromotedInteger(RHS);
      return DAG.getNode(ISD::SHL, SDLoc(N), LHS.getValueType(), LHS, RHS);
#else

  SDValue Res = GetPromotedInteger(N->getOperand(0));
  SDValue Amt = N->getOperand(1);
  Amt = Amt.getValueType().isVector() ? ZExtPromotedInteger(Amt) : Amt;
  return DAG.getNode(ISD::SHL, SDLoc(N), Res.getValueType(), Res, Amt);
#endif



Where the code inside #ifdef LATEST is the new code.

I hit the same kind of issue in “PromoteIntRes_SimpleIntBinOp” where trunk code
doesn’t have similar fix.

The attached patch expands that fix to other legalize op functions


Attachments:

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160629/64e9cb83/attachment.html>