<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jul 14, 2014, at 7:23 AM, Tom Stellard <<a href="mailto:tom@stellard.net">tom@stellard.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Mon, Jul 14, 2014 at 01:08:54PM +0100, Tim Northover wrote:<br><blockquote type="cite">Hi all,<br><br>What do people think of doing away with the @llvm.convert.to.fp16 and<br>@llvm.convert.from.fp16 intrinsics, in favour of using "half" and<br>fpext/fptrunc? [1]<br><br></blockquote><br>I am in favor of using fpext/fptrunc instead of the intrinsics.<br></div></blockquote><div><br></div><div><br></div><div>The problem with this is the half type assumes you have half registers. I came up with some ugly hack that involved forcing custom lowering to make half loads/stores work for R600, but it was much easier to handle the intrinsic. The 16-bit integer type extload to the 32-bit register with the intrinsic for the half conversion just worked (see r212676)</div><div><br></div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br><blockquote type="cite">It looks like those intrinsics originally date from before "half"<br>actually existed in LLVM, and of course the backends have grown up<br>assuming that's what Clang will produce, so we'd have to improve their<br>support first. But the benefit would be a more uniform interface to<br>this type, both for front-ends and backends.<br><br>I've been poking around a bit, and as far as I can see the following<br>accommodations would need to be made in CodeGen:<br><br>1. Generic support to Promote f16 operations narrowed by InstCombine<br>back to f32.<br><br></blockquote><br>Are there any in-tree targets that natively support fp16 operations?<br><br>-Tom<br><br><blockquote type="cite">And in Targets:<br><br>1. If there's *no* native f16 support, they can probably remain unchanged.<br>2. Targets with scalar f16 conversion would need it to become a legal<br>type (in some register class). This seems like a reasonable<br>requirement if there actually are instructions acting on it. But it<br>adds the usual overheads of supporting bitcasts and loads/stores.<br>3. Targets with vector f16 conversion would similarly need to legalize<br>the type (and in this case would probably need argument-passing<br>support too, since Clang forbids passing a direct __fp16 but not a<br>vector).<br><br>I think it would be a worthwhile change, but want to make sure backend<br>owners with an interest in f16 don't object to the direction. That'd<br>seem to be: AArch64, ARM, NVPTX, R600 and X86.<br><br>Cheers.<br><br>Tim.<br><br>[1] I think this is an orthogonal issue to whether __fp16 is a<br>storage-only type or actually gets native arithmetic operations: we<br>can still have Clang promote any value to float before actually doing<br>anything.<br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a><span class="Apple-converted-space"> </span> <a href="http://llvm.cs.uiuc.edu/">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></div></blockquote></div><br></body></html>