On 19 October 2016 at 03:03, Jeff Law <l...@redhat.com> wrote:
> 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.
Err no, that poor decision was entirely mine -;) I had wrongly
assumed __udivmoddi4 to be always available
and got surprised when it gave undefined reference error on aarch64
and hence brought it up for discussion.
I removed those parts of the patch that generated call to
__udivmoddi4() before posting the patch upstream.
>>> 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.