This is an archive of the discontinued LLVM Phabricator instance.

Do not ASSERTZEXT for i16 result of bitcast from f16 operand
ClosedPublic

Authored by pirama on Dec 10 2015, 6:20 PM.

Details

Summary

During legalization if i16, do not ASSERTZEXT the result of FP_TO_FP16.
Directly return an FP_TO_FP16 node with return type as the
promote-to-type of i16.

This patch also removes extraneous length check. This legalization
should be valid even if integer and float types are of different
lengths.

This patch breaks a hard-float test for fp16 args. The test is changed
to allow a vmov to zero-out the top bits, and also ensure that the
return value is in an FP register.

Diff Detail

Repository
rL LLVM

Event Timeline

pirama updated this revision to Diff 42490.Dec 10 2015, 6:20 PM
pirama retitled this revision from to Do not ASSERTZEXT for i16 result of bitcast from f16 operand.
pirama updated this object.
pirama added reviewers: ab, jmolloy.
pirama added subscribers: llvm-commits, srhines.
jmolloy edited edge metadata.Dec 11 2015, 3:38 AM

Hi Pirama,

Can you explain why this is necessary? Why is ASSERTZEXT not correct in this case?

James

Hi James,

Can you explain why this is necessary? Why is ASSERTZEXT not correct in this case?

ASSERTZEXT does not generate any instructions but just records that its input operand is zero extended. When I wrote this code initially, I incorrectly inserted this ASSERTZEXT while extending the result from i16 to i32. That later causes the backend to assume that the top bits are zero and incorrectly use the 'orr' instruction (https://llvm.org/bugs/show_bug.cgi?id=25492). Removing the ASSERTZEXT forces the backend to use uxth and pkhbt.

jmolloy accepted this revision.Dec 12 2015, 5:31 AM
jmolloy edited edge metadata.
This revision is now accepted and ready to land.Dec 12 2015, 5:31 AM
This revision was automatically updated to reflect the committed changes.