<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - LLVM legalizer crashes when target legalizes some operation and LLVM legalizes some"
href="https://llvm.org/bugs/show_bug.cgi?id=28365">28365</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>LLVM legalizer crashes when target legalizes some operation and LLVM legalizes some
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Macintosh
</td>
</tr>
<tr>
<th>OS</th>
<td>MacOS X
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Common Code Generator Code
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>hisham_chow@yahoo.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=16650" name="attach_16650" title="patch">attachment 16650</a> <a href="attachment.cgi?id=16650&action=edit" title="patch">[details]</a></span>
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:</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>