[PATCH][ARM]Fix urem/srem of i64 for aeabi target (PR 17881)

[Renato Golin]

On 12 November 2013 01:15, Weiming Zhao <weimingz at codeaurora.org> wrote:

> I actually did something similar with your patch #1 (custom lower
> DIVMOD64) and I couldn’t get it work either.
>
> The problem is legalize occurs earlier.
>
>
Precisely. This is why we created the 64-bit fake DAG nodes. It didn't get
much easier, though.


And another tricky thing is the second half of the return value
of__aeabi_divmod is needed.
>
> 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)
>
>
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.

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.

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.


I read the other patch (devmod-legal) and seems OK. Why doesn’t it work?
>
>
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. ;)

Good luck!
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131112/3602ae3f/attachment.html>