<div dir="ltr">On 16 July 2013 09:19, Kristof Beyls <span dir="ltr"><<a href="mailto:kristof.beyls@arm.com" target="_blank">kristof.beyls@arm.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">1.<span style="font-size:7pt;font-family:'Times New Roman'">       </span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Quite a few test cases seem to be computing (a%b)+(a/b)+(b%a).</span><br>
</p><p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">For these test cases I can see for “GNU” and “DARWIN” that the regression tests look for 2 add instructions,<br>but for EABI, the tests only look for 1 add instruction.<br>
I think that the checks should look for 2 add instructions, adding the right registers.</span></p></div></div></blockquote><div>__aeabi_idivmod returns the remainder in R1, while in GNU and DARWIN the mod is calculated by calling __modsi3, and that makes the scheduler to create the sum register by adding the quotient to it first, than adding the remainder. Since the AEABI call returns both at the same time, it only needs to add once (or save the value on a scratch register, the mov in the test).</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p><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">On test case longf, there’s a FIXME saying “AEABI is not lowering long u/srem into u/ldivmod”, yet there is<br>
a check for EABI that __aeabi_ldivmod is produced. Is the FIXME comment still correct? If the FIXME<br>is no longer correct, there probably also should be checks for add instructions in this test case?</span></p></div></div>
</blockquote><div>The FIXME is still relevant, since on that function, only the first part (div + mod) is converted into a divmod call, while the latter (mod) remains as a call to __modsi3, which shouldn't even appear on AEABI code in the first place.</div>
<div><br></div><div>That FIXME is my next task, where I'll try to make UREM/SREM calls also lower to __aeabi_*divmod and move the remainter to the quotient (R1->R0 or R2,R3->R0,R1) afterwards, hopefully using the same lowering function.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>3.<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">Test case g1: “DARWIB” -> “DARWIN”</span></p>
</div></div></blockquote><div></div></div><br></div><div class="gmail_extra">Fixed.</div><div class="gmail_extra"><br></div><div class="gmail_extra">cheers,</div><div class="gmail_extra">--renato</div></div>