<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;">Hi,<div><br></div><div>Here is a patch to improve the instruction selection of vector loads on ARM.</div><div>Thanks for your review.</div><div><br></div><div>** Problematic **</div><div>In the ARM back-end, build_vector nodes are lowered to a target specific build_vector that uses floating point type[1]. </div><div><div>This works well, unless the inserted bitcasts survive until instruction selection. In that case, they incur moves between integer unit and floating point unit that may result in inefficient code.</div></div><div><br></div><div>In other words, this conversion may introduce artificial dependencies when the code leading to the build vector cannot be completed with a floating point type.</div><div><br></div><div>In particular, this happens when loads are not aligned.</div><div><br></div><div>In that case, the compiler generates general purpose loads and creates the floating point vector from them, instead of directly using the vector unit.</div><div><br></div><div><<a href="rdar://problem/14170854">rdar://problem/14170854</a>></div><div><br></div><div>[1] The rational is that floating point registers are aliases of vector registers.</div><div><br></div><div>** Motivating Example **</div><div>The attached motivating_example.ll demonstrates that (also part of a test case in the proposed patch).</div><div><br></div><div>To reproduce:</div><div>llc -O3 -mtriple thumbv7-apple-ios3 motivating_example.ll -o -</div><div><div style="margin: 0px; font-size: 11px; font-family: Menlo;"><span class="Apple-tab-span" style="white-space: pre;"> </span>ldr<span class="Apple-tab-span" style="white-space: pre;"> </span>r0, [r1]</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;"><span class="Apple-tab-span" style="white-space: pre;"> </span>ldr<span class="Apple-tab-span" style="white-space: pre;"> </span>r1, [r2]</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;"><span class="Apple-tab-span" style="white-space: pre;"> </span>vmov<span class="Apple-tab-span" style="white-space: pre;"> </span>s1, r1</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;"><span class="Apple-tab-span" style="white-space: pre;"> </span>vmov<span class="Apple-tab-span" style="white-space: pre;"> </span>s0, r0</div></div><div style="margin: 0px;">Here each ldr, vmov sequences could have been replaced by a simple vld1.32.</div><div><br></div><div>** Proposed Solution **</div><div>Use a vector friendly sequence of code when the inserted bitcasts to floating point survived DAGCombine.</div><div><br></div><div><div>Thanks for Eli Friedman for the direction!</div></div><div><br></div><div>This is done by a target specific DAGCombine that changes the target specific build_vector into a sequence of insert_vector_elt that get rid of the bitcasts.</div><div><br></div><div>Thanks for your review.</div><div><br></div><div>Cheers,</div><div><br></div><div apple-content-edited="true">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">-Quentin</div>
</div>
</body></html>