Daniel Towner <[EMAIL PROTECTED]> 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
