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? Richard. > Thanks, > Prathamesh > > > > jeff > > > > -- Richard Biener <rguent...@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
