<div dir="ltr">On 12 November 2013 01:15, Weiming Zhao <span dir="ltr"><<a href="mailto:weimingz@codeaurora.org" target="_blank">weimingz@codeaurora.org</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-US" link="blue" vlink="purple"><p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">I actually did something similar with your patch #1 (custom lower DIVMOD64) and I couldn’t get it work either. </span><br>
</p><pre><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The problem is legalize occurs earlier.</span></pre></div></blockquote><div><br></div><div>Precisely. This is why we created the 64-bit fake DAG nodes. It didn't get much easier, though.</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-US" link="blue" vlink="purple"><pre><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></pre>
<pre><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">And another tricky thing is the second half of the return value of__aeabi_divmod is needed. </span><br></pre><pre><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">SDIV/UDIV is easier because no matter __adabi_uldivmod or  “__udivdi3” is selected, the only difference is the function name. See (LegalizeIntegerTypes.cpp::ExpandIntRes_SDIV(), where a i64 div is converted to function call)</span></pre>
</div></blockquote><div><br></div><div>Yes. This is one of the reasons I wanted to consolidate the __value_in_regs implementation before proceeding. But it seems there will be no difference in this area, so we're good to go.</div>
<div><br></div><div>The main problem with __value_in_regs is that it could mean many things, in different contexts. For instance, GNU's divmod has one value in register, and one on the stack, while __value_in_regs is normally used to say that none of the values are on the stack. Also, if you say an ABI is __value_in_regs, then you assume that *all* library calls will have value in regs, or none if it's missing, which is not true for GNU.</div>
<div><br></div><div>This is why I wanted a special flag just for divmod. But that wasn't considered as a good approach. My view is that, the current implementation is GNU specific, which is already not good. Making it understand different ABIs woulnd't make it worse. If there was a canonical way of doing it (non-GNU), than I understand why not adding ABI issues to the generic code. But as it stands, it's already ABI-specific.</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-US" link="blue" vlink="purple"><pre><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></pre>
<pre><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">I read the other patch (devmod-legal) and seems OK. Why doesn’t it work?</span></pre></div></blockquote><div><br></div><div>It does. But people were uncomfrotable with the notion of having ABI-specific knowledge in generic code. But as I said, it's already ABI-specific (GNU's), so I don't agree with that argument. However, they were all against me, so I yielded. ;)</div>
<div><br></div><div>Good luck!</div><div>--renato</div></div></div></div>