Re: Lazy construction of libcalls

[Andrew Haley <aph-gcc@littlepinkcloud.COM>]

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.

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

Andrew.


2007-09-08  Andrew Haley  <aph@redhat.com>

        * optabs.c (sign_expand_binop): Set libcall_gen = NULL in the fake
        signed optab.

Index: gcc/optabs.c
===================================================================
--- gcc/optabs.c        (revision 128099)
+++ gcc/optabs.c        (working copy)
@@ -2234,6 +2234,9 @@
      hides any signed insn for direct use.  */
   wide_soptab = *soptab;
   optab_handler (&wide_soptab, mode)->insn_code = CODE_FOR_nothing;
+  /* We don't want to generate new hash table entries from this fake
+     optab.  */
+  wide_soptab.libcall_gen = NULL;
 
   temp = expand_binop (mode, &wide_soptab, op0, op1, target,
                       unsignedp, OPTAB_WIDEN);