Re: Lazy construction of libcalls

[Jan Hubicka <jh@suse.cz>]

> Jan Hubicka writes:
>  > > Jan Hubicka <jh@suse.cz> writes:
>  > > >> Jan Hubicka <jh@suse.cz> writes:
>  > > >> > While comparing the tables produced by new and old code, I noticed that
>  > > >> > "ffs" for SI used to be called "ffssi3" but now it is "ffs".
>  > > >> > I believe it was inteded to be called ffs because of:
>  > > >> >   optab_handler (ffs_optab, int_mode)->libfunc = init_one_libfunc ("ffs");
>  > > >> > that however later get overwriten by initialization code.
>  > > >> 
>  > > >> Actually, this was deliberate.  All libgccs have word and doubleword
>  > > >> ffs functions, but not all C libraries have "ffs".  So we wanted the
>  > > >> libgcc versions to take precedence over the C library fallback.  See:
>  > > >> 
>  > > >>     http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01165.html
>  > > >> 
>  > > >> for details.
>  > > >
>  > > > OK, so the initialization of libgcc always overwrite the ffs
>  > > > initialization, so simply removing the line above would work?
>  > > 
>  > > Not for 64-bit targets with a 32-bit int, since __builtin_ffs() takes
>  > > an int argument.  We could of course add an SImode libgcc function for
>  > > those targets, but the patch above was just supposed to make better
>  > > use of what we already had.
>  > 
>  > Thanks for explanation - I've now added a guard 
>  > if (INT_TYPE_SIZE < BITS_PER_WORD)
>  > into my local copy that should do what described again. I am re-testing now,
>  > OK with that change?
> 
> This breaks ARM EABI.  The symptom is that we generate signed instead
> of unsigned libcalls for a % b where a and b are usigned ints.
> 
> The problem is here in sign_expand_binop(), where we generate a fake
> optab:
> 
>   /* Try widening to a signed int.  Make a fake signed optab that
>      hides any signed insn for direct use.  */
>   wide_soptab = *soptab;
>   optab_handler (&wide_soptab, mode)->insn_code = CODE_FOR_nothing;
>  
> We later call expand_binop (mode, &wide_soptab ...  which in turn
> calls optab_libfunc (binoptab, mode) which calls optab->libcall_gen()
> and inserts the fake optab into the hash table.  This means that the
> hash table ->optab points into the stack.  We don't want to do this,
> I'm sure.

Uh, sure...
> 
> I suspect the easiest way to fix this is by setting libcall_gen to
> NULL in the fake optab.

Thanks, that seems like correct fix to me.

Honza