On 10/17/2016 11:23 PM, Prathamesh Kulkarni wrote:
The divmod transform isn't enabled if target supports hardware div in
the same or wider mode even if divmod libfunc is available for the
given mode.
Good. That seems like the right thing to do.
Thanks. I had erroneously assumed __udivimoddi4() was available for
all targets because it was defined in libgcc2.c and generated call to
it as "last resort" for unsigned DImode case if target didn't support
hardware div and divmod insn and didn't have target-specific divmod
libfunc for DImode. The reason why it generated undefined reference
on aarch64-linux-gnu was because I didn't properly check in the patch
if target supported hardware div, and ended up generating call to
__udivmoddi4() even though aarch64 has hardware div. I rectified
that before posting the patch.
Understood. From a design standpoint, it seems to me like the path
where we emit a call to udivmod without knowing if its supported by
libgcc is broken. But if I understand correctly, that's not affected by
your changes -- it's simply a historical poor decision.
I don't even think we have a way of knowing in the compiler if the
target has enabled divmod support in libgcc.
Well the arm and c6x backends register target-specific divmod libfunc
via set_optab_libfunc(). I suppose that's sufficient to know if
target has divmod enabled in libgcc ?
It's probably a pretty reasonable assumption that if the target has
registered a libfunc, the the libfunc ought to be available.
ISTM that for now we have to limit to cases where we have a divmod
insn/libcall defined.
Indeed. The transform is enabled only if the target has hardware
divmod insn or divmod libfunc (in the libfunc case, no hardware div
insn). Please see divmod_candidate_p() in the patch for cases when
the transform gets enabled.
Great. Thanks. Hoping to make some progress on the actual patch in the
next couple days.
jeff
