On 10/15/2016 11:59 PM, Prathamesh Kulkarni wrote:
This touches on the one high level question I had. Namely what is the
code generation strategy if the hardware has a div, but not divmod.
This patch is mostly the same as previous one, except it drops
targeting __udivmoddi4() because it gave undefined reference link
error for calling __udivmoddi4() on aarch64-linux-gnu. It appears
aarch64 has hardware insn for DImode div, so __udivmoddi4() isn't
needed for the target (it was a bug in my patch that called
__udivmoddi4() even though aarch64 supported hardware div).
ISTM in that case I think we want to use the div instruction and
synthesize mod from that result rather than relying on a software
divmod. So it looks like you ought to be doing the right thing for that
case now based on your comment above.
I don't think that's a safe assumption. Addition of the divmod routines
into libgcc is controlled by the target and have to be explicitly added
However this makes me wonder if it's guaranteed that __udivmoddi4()
will be available for a target if it doesn't have hardware div and
divmod insn and doesn't have target-specific libfunc for DImode
divmod ? To be conservative, the attached patch doesn't generate call
So on a target like the fr30 which has no div or mod insn and doesn't
define the right bits in libgcc, there is no divmod libcall available.
(On these targets there's a div libcall and a mod libcall, but not a
I don't even think we have a way of knowing in the compiler if the
target has enabled divmod support in libgcc.
ISTM that for now we have to limit to cases where we have a divmod