Re: slow V3 configures (was Re: ICE during bootstrap.)

[Raja R Harinath <harinath at cs dot umn dot edu>]

Phil Edwards <pedwards@disaster.jaj.com> writes:
> On Tue, Dec 05, 2000 at 11:53:57AM -0800, Benjamin Kosnik wrote:
> > Following phil's advice and changing to
> > 
> >    test-for-cached-answer-oh-it's-there-never-mind
> >    else
> >      push-current-language-on-stack
> >      set-current-language-to-C++
> >      test and cache
> >      pop-language-from-stack
> >    end   
> > 
> > seems like the best approach.
> 
> The odd thing is...  this is what should be happening now.  All the
> push-set-test-cache-pop stuff is done inside the list of commands "to be
> run if the value isn't cached".  We still get serious pauses.

Well, not exactly.  What's happening is

  if have cached_answer; then :;
  else
    execute test to check for declaration and update cached_answer
  fi
  if test $cached_answer = yes; then
     AC_CHECK_FUNCS($1)
  fi

AC_CHECK_FUNCS uses a for loop, which executes even if the cached
answer is returned.  That's probably where all that time is lost.

One option is to use AC_CHECK_FUNC, but you lose the automatic
definition of HAVE_FOO and corressponding updates of config.h.in.
Another is to have parallel tests. 

  GLIBCPP_MATH_DECL_1(sinf)
  GLIBCPP_MATH_DECL_1(isnanf)
  GLIBCPP_MATH_DECL_2(hypotf)
  ...
  # check these unconditionally
  AC_CHECK_FUNCS(sinf isnanf hypotf ...)

This may increase the 'configure' time somewhat for the first time,
but is likely to zoom through on re-runs.
 
> Anyhow, I patched all the math tests to explictly do the same test that
> AC_CACHE_VAL does before calling AC_CACHE_VAL itself.  The speedup is
> /considerable/.  The config.cache and bits/c++config.h results are identical.
> 
> One downside:  it's AC_CACHE_VAL that does the printing of "(cached)".
> My change means that a cached value still shows on the screen as
> 
>     checking for _expf declaration... no
>     checking for _fabsf declaration... no
>     checking for _floorf declaration... no
>     checking for _fmodf declaration... no
>     checking for _frexpf declaration... no
>     checking for _ldexpf declaration... no

Looks like you are skipping the 

  if test x$glibcpp_cv_func_$1_use = x"yes"; then
    AC_CHECK_FUNCS($1)    
  fi

part, so it's probably not a valid comparison :-)

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash