On 10/15/2016 11:59 PM, Prathamesh Kulkarni wrote:
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).
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.
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.
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
to __udivmoddi4.
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
AFAICT.
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
combined one).
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
insn/libcall defined.
jeff
