Re: Queries regarding calls to divmod assembly functions (sans disclaimer)

[Ian Lance Taylor <iant at google dot com>]

Daniel Towner <d_w_towner@yahoo.co.uk> writes:

> Initially, I tried to do as the manual suggested, and omit any patterns 
> for div/mod, to force gcc to use divmod instead, and setup the divmod 
> optab to call a named assembly function. However, div would still call a 
> div library, instead of the divmod library. So I set the div optab 
> library function to null. Unfortunately this didn't appear to work; 
> while the absence of any instruction pattern or library function works 
> for mod (it generates a call to the appropriate library), the div 
> expansion (in expand_divmod) seems to fail if no library or no 
> instruction pattern is available, and leaves the function without trying 
> a divmod library call. This results in the last part of expand_divmod 
> trying to call gen_lowpart on a NULL_RTX. Is that correct? It seems easy 
> to add a call to a divmod library as a last resort, but will that 
> adversely affect other ports?

The missing call to a divmod libfunc does seem like a bug.  I don't
see how it could be a bad idea for other ports, since, as you say, the
compiler simply fails in that case.


> Next I tried to make the divmodM4 patterns generate a call directly to 
> my divmod function by having a define_expand which invokes 
> expand_twoval_binop_libfunc. This means that when the expand_divmod 
> function is run, it finds the divmod instruction, which it then 
> indirectly uses to generate the divmod library call. This appears to 
> work as I expect. Are there any gotchas I should be aware of in doing this?

I don't think you can always safely call expand_twoval_binop_libfunc
from the expander.  That probably won't do the right thing if some
later part of the compiler decides to generate a divmod insn.  I think
the only safe thing you can do is to set up the function arguments and
do the call yourself.  That should be easy in a define_expand if the
parameters can be passed in registers--and that might be a good idea
for the divmod function even if it is not the normal calling
convention.


> Now I have two final queries with this scheme. Firstly, if the source 
> code contains a div and a mod in quick succession, then I end up with 
> two calls to my divmod routine, although the instruction sequences to 
> set up the two calls are identical. Are there any tweaks I can apply to 
> allow the result of the first call to be reused, ratehr than calling the 
> function again? Secondly, the SI mode version of the function returns 
> the two data values by passing in an address to which to write the 
> values. I can make the functions smaller and faster by changing the 
> calling convention for just that function (i.e., return in registers 
> instead), but how should I go about fixing the gcc end to call the 
> functions differently? Should I explicitly emit the instructions to set 
> up the call in the divmodsi4 define_expand, or should I change the ABI 
> to be different for that one function, if possible?

Change the define_expand.  This would be a good reason to use a
define_expand rather than a libfunc.

I would like to think that gcc would be able to eliminate a pair of
div/mod calls.  The way you are doing it may require emitting some
explicit REG_EQUAL notes for both results of the function call.

Ian