[PATCH] D15438: Do not ASSERTZEXT for i16 result of bitcast from f16 operand

James Molloy via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 11 11:38:36 PST 2015


OK , thanks for the explanation. This now LGTM.
On Fri, 11 Dec 2015 at 19:30, Pirama Arumuga Nainar via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> pirama added a comment.
>
> 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.
>
>
> http://reviews.llvm.org/D15438
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151211/5665ae2a/attachment.html>


More information about the llvm-commits mailing list