> On May 31, 2018, at 12:35 PM, Joseph Myers <jos...@codesourcery.com> wrote:
>
> On Tue, 29 May 2018, Paul Koning wrote:
>
>> Question about proper target maintainer procedures...
>>
>> The pdp11 target needs udivhi3 in libgcc. There's udivsi3, and it's
>> really easy to tweak those files for HImode. And that works.
>>
>> Should I add the HI files to the libgcc directory, or under
>> config/pdp11? There's nothing target specific about them, though I
>> don't know of other targets that might want this.
>
> The existing mechanism for building libgcc functions for different types
> is LIBGCC2_UNITS_PER_WORD. That may be defined in target .h files
> (currently those in gcc/), and also via siditi-object.mk which is used to
> build certain conversion functions for multiple types.
>
> As I understand it, you want to build certain non-conversion functions for
> multiple type as well. There are a few libgcc/config files that do define
> LIBGCC2_UNITS_PER_WORD to 2 before defining some L_* macros and including
> libgcc2.c, in order to define HImode functions (libgcc2.h then deals with
> getting the functions appropriately named via the definitions of __NW and
> __NDW, and getting them to use the right types via definitions of Wtype
> etc.).
>
> So you could just add such a file to config/pdp11, or you could try to
> develop a more general mechanism for targets to select HImode functions
> they want built in libgcc and for the common build machinery then to build
> those functions (and then refactor how existing targets build such
> functions accordingly).
I see udivdi in libgcc2.c, but udivsi is provided in separate file udivmod.c.
That was introduced in 2001 by Rainer Orth. This code is used in three
targets that I can see: cr16, iq2000, and pdp11.
So it sounds like the cleaner answer is to generalize the libgcc2 code to
provide the different length [u]div functions needed: DI for whoever uses it
now, SI for those three, and HI for pdp11. I can give that a try, it's a
more complex change but generality seems good.
paul
