[PING] set libfunc entry for sdivmod_optab to NULL in optabs.def

Richard Sandiford rdsandiford@googlemail.com
Thu Sep 15 03:08:00 GMT 2016


Richard Sandiford <rdsandiford@googlemail.com> writes:
> Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org> writes:
>> Hi,
>> I would like to ping the following patch:
>> https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01015.html
>>
>> While implementing divmod transform:
>> https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01757.html
>>
>> I ran into an  issue with optab_libfunc().
>> It appears optab_libfunc (sdivmod_optab, mode) returns
>> bogus libfunc for unsupported modes, for instance
>> on x86_64, optab_libfunc (sdivmod_optab, DImode) returns
>> a libfunc with name "__divmoddi4", even though such a libfunc
>> does not exist in libgcc. This happens because in optabs.def
>> the libfunc entry for sdivmod_optab has gen_int_libfunc,
>> and call to optab_libfunc (sdivmo_optab, DImode) lazily
>> creates a bogus libfunc "__divmoddi4" by calling gen_int_libfunc().
>>
>> To work around this issue I set libfunc entry for sdivmod_optab to NULL
>> and verified that optab_libfunc (sdivmod_optab, DImode) returns NULL_RTX
>> instead of a bogus libfunc if it's not overriden by the target.
>>
>> Bootstrapped and tested on ppc64le-linux-gnu, x86_64-linux-gnu.
>> Cross tested on arm*-*-*, aarch64*-*-*.
>> OK for trunk ?
>
> I'm not a maintainer for this area, but:

...in https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01757.html
you said that c6x follows the return-by-pointer convention.
I'm no c6x expert, but from a quick look, I think its divrem
function returns a div/mod pair in A4/A5, which matches the
ARM convention of returning both results by value.

Does anyone know if the optab function registered by the SPU
backend is ever called directly?

You mention that this is latent as far as expand_twoval_binop_libfunc
is concerned.  AIUI expand_twoval_binop_libfunc implements the ARM/c6x
convention and expects the two values to be returned as a pair.
It then extracts one half of the pair and discards the other.
So my worry is that we're leaving the udivmod entry intact even though
the standard __udivmoddi4 doesn't do what expand_twoval_binop_libfunc
expects.

Would it make sense to set both entries to null and treat __udivmoddi4
as a non-optab function?  ARM and c6x could then continue to register
their current optab functions and a non-null optab function would
indicate a return value pair.

Sorry if this has already been covered.

Thanks,
Richard



More information about the Gcc-patches mailing list