On 18 October 2016 at 13:55, Richard Biener <rguent...@suse.de> wrote: > On Tue, 18 Oct 2016, Prathamesh Kulkarni wrote: > >> On 18 October 2016 at 02:46, Jeff Law <l...@redhat.com> wrote: >> > 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. >> 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. >> > >> > 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). >> 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. >> > >> > I don't even think we have a way of knowing in the compiler if the target >> > has enabled divmod support in libgcc. > > Yeah, that's what bothers me with the current optab libfunc query > setup -- it isn't reliable. > >> 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 ? >> > >> > 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. > > But after your patch the divmod libfunc is never available? After the patch, the divmod libfunc is not available if the target doesn't explicitly set it. So by default optab_libfunc ([us]divmod_optab, mode) would return NULL instead of bogus libfunc constructed with gen_int_libfunc, but if the target has registered it with set_optab_libfunc, then the target-specific libfunc name would be returned.
Thanks, Prathamesh > > Richard. > >> Thanks, >> Prathamesh >> > >> > jeff >> > >> >> > > -- > Richard Biener <rguent...@suse.de> > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB > 21284 (AG Nuernberg)
