<div dir="ltr">Hi Ana,<div><br></div>>2)      Using v1ix and v1fx to represent Neon scalar data types in the backend.<br><br>For this point, I agree that introduce v1i8 and v1i16 to protect 8 bit and 16 bit integer value type, but why we need v1i32 , v1i64 ,v1f32 and v1f64?<br>
<br>From my perspective, DAG should only hold operations with value type, but not a certain register class. Which register class to be used is decided by compiler after some cost calculation. If we bind v1i32 and v1i64 to FPR, then it's hard for compiler to make this optimization. <br>
<br>Consider this case, if we introduce  v1i32 and v1i64, what the output value of EXTRACT_VECTOR_ELT should be? If the value is i32, then only 'umov Wx, Vx.s[lane]' can be selected(i32 bind to GPR); if the value if v1i32, only 'ins Vx.s[0], Vx.s[lane]' can be selected(v1i32 bind to FPR). This maybe introduce extra mov instruction even load/store instruction if registers aren't enough. Better choice is binding i32 to both GPR and FPR, and let compiler to decide which instruction should be emitted considering context and register pressure.<br>
<br>Also, f32 and f64 have already bind to FPR with no conflict, I don't know why we need v1f32 and v1f64. I know v1f64 is used in ACLE intrinsic, but we can convert it to f64 in LLVM IR, so it should not be seen in both middleend and backend.
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/9/13 Ana Pazos <span dir="ltr"><<a href="mailto:apazos@codeaurora.org" target="_blank">apazos@codeaurora.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi Tim and Jiangning,<u></u><u></u></span></p><p class="MsoNormal">
<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The patches bring up a couple discussion points:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p style="margin-left:.25in"><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>1)<span style="font:7.0pt "Times New Roman"">      </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Type of code generated by ACLE Neon intrinsics<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:.25in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">From what I have experimented with, to guarantee only Neon code is generated for the ACLE Neon intrisics, you will need to use builtins and translate those builtins into LLVM intrinsics.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Otherwise you are vulnerable to the compiler capabilities (e.g., current/future optimizations, data layout changes) and might not generate the expected Neon instructions.<u></u><u></u></span></p>
<p style="margin-left:.25in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">If this is not a requirement, than the way we generate tests for ACLE Neon intrinsics in NeonCodeEmitter needs to be fixed. We cannot auto generate “//CHECK” strings with the Neon instructions.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p style="margin-left:.25in"><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>2)<span style="font:7.0pt "Times New Roman"">      </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Using v1ix and v1fx to represent Neon scalar data types in the backend. <u></u><u></u></span></p>
<p style="margin-left:.25in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">This is the important decision we need to make soon.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">ARMv8 supports 64, 32, 16 and 8 bit scalar operations in Neon.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I think the compiler should be able to distinguish when to generate Neon scalar from non-Neon scalar operations.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">How to achieve that without defining different data types? Only through using Neon intrinsics?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Regarding impact on middle end optimizations effectiveness:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">This is my understanding. Tim and others, correct me if I got it wrong.<u></u><u></u></span></p><p class="MsoNormal">
<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The data layout string defined for AArch64 only contains 32 and 64 as native types. <u></u><u></u></span></p><p class="MsoNormal">
<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">See AArch64TargetInfo::DescriptionString in tools\clang\lib\Basic\Targets.cpp: <b>n32:64</b><u></u><u></u></span></p><p class="MsoNormal">
<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The middle end uses this data layout information to perform the optimizations.<u></u><u></u></span></p><p class="MsoNormal">
<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Right now it promotes sub-word data types to 32-bit. You can see the generation of “sext” IR operations when you emit LLVM code. I do not see it doing sub-word optimizations.<u></u><u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> <u></u><u></u></span></b></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">If this data layout is in the future changed to <b>n8:16:32:64 </b>and we use ixx and fxx for Neon scalar types, we will have more mix of Neon and Non-neon code, more copy operations between Neon and Non-neon registers which can have a bad impact on performance.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hope Tim and the community can give me some more guidance in this area.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Ana.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Jiangning Liu [mailto:<a href="mailto:liujiangning1@gmail.com" target="_blank">liujiangning1@gmail.com</a>] <br>
<b>Sent:</b> Wednesday, September 11, 2013 11:32 PM<br><b>To:</b> Ana Pazos<br><b>Cc:</b> Tim Northover; <a href="mailto:rajav@codeaurora.org" target="_blank">rajav@codeaurora.org</a>; llvm-commits; <a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<b>Subject:</b> Re: [PATCH][AArch64]RE: patches with initial implementation of Neon scalar instructions<u></u><u></u></span></p><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><div><div><p class="MsoNormal">
Ana,<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">I personally think acle functions for neon should be expected to generate neon instruction, because it would be able to ask compiler to generate special instructions supporting complex functionality.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div></div><div><p class="MsoNormal">The test case given by Tim should be able to still generate "<span style="font-size:11.0pt;font-family:"Arial","sans-serif"">add d0, d1, d0</span>", if you define vaddd_s64 using vadd_s64, rather than using an IR intrinsic.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Since most of middle end optimizations are based on scalar data type, if we use v1ixx instead of ixx, do we have any scenario to lose optimization opportunities in middle end? Or we don't care about that at all, because this is being introduced by acle intrinsics. I'm also fine with this conclusion.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Thanks,<u></u><u></u></p></div><div><p class="MsoNormal">-Jiangning<u></u><u></u></p></div></div></div></div></div></div><br>_______________________________________________<br>

cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Best Regards,<div><br></div><div>Kevin Qin</div></div>
</div>