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. Thanks!
Regards, Prathamesh > > jeff
