Re: RFC [1/3] divmod transform v2

[Jeff Law <law@redhat.com>]

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.

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).

I don't even think we have a way of knowing in the compiler if the 
target has enabled divmod support in libgcc.

ISTM that for now we have to limit to cases where we have a divmod 
insn/libcall defined.

jeff