Re: [PATCH][fortran] Make cbrt, cexpi and sincos builtins available

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 1/4/07, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
> On Mon, Jan 01, 2007 at 01:07:28PM +0100, Richard Guenther wrote:
> > On 12/15/06, Jerry DeLisle <jvdelisle@verizon.net> wrote:
> > >Tobias Burnus wrote:
> > >> Let's    *ping*   for Richard.
> > >>
> > >> with the sincos infrastructure in the middle end (I think all patches
> > >> are now in the trunk), this speeds up the Polyhedron fatigue test a lot:
> > >> ~28.3s => ~18.3s  (35% faster).
> > >>
> > >> This can be seen at the page
> > >>
> > >http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-fatigue-15.png
> > >> of http://www.suse.de/~gcctest/c++bench/polyhedron/
> > >> (The patch was applied for one day.)
> > >>
> > >> Tobias
> > >>
> > >> Richard Guenther schrieb:
> > >>> As $subject says.  The cbrt builtins can be used to expand x**1./3. to
> > >>> cbrt, the other two are on-top of the sincos patches.
> > >>>
> > >>> Bootstrap / regtest running.
> > >>>
> > >>> Ok if the sincos patch(es) go in?  How can we tell that the target
> > >>> supports sincos?  (I guess we would need a configure check for that?)
> > >>>
> > >
> > >It was not clear to me the consequences of the question about needing a
> > >configure check.  Has that been addressed?
> >
> > No, it has not been addressed.  As far as I see we do not have
> > infrastructure
> > in place to have tests on the target system in gcc/ because it wouldn't work
> > if we are cross-compiling.  We would need to do a two-stage compile in
> > the cross-compiling case as well - first build a cross compiler to be able
> > to compile/link target configure tests and then after those tests rebuild.
> >
> > So the canonical way of introducing target dependencies in gcc/ is to
> > augment the gcc/config/ stuff with target macros/hooks dependent on
> > the target system.
> >
> > For builtins, the __builtin_* variant is always available even if the target
> > does not provide a library implementation (see PR29719 for where this
> > causes a problem).
> >
> > For the bare variant we only
> > have a destinction for TARGET_C99_FUNCTIONS - which doesn't help
> > in the case of sincos, as that is a (common) extension.  Also
> > TARGET_C99_FUNCTIONS is said to be too broad (see PR30181).
> >
> > So before going down the route adding TARGET_HAS_SINCOS and
> > maybe lots of TARGET_HAS_C99_XYZ - are there better suggestions on
> > how to address the problems above?
> >
>
> Richard perhaps I misunderstand your last 3 paragraphs  Are you aware
> that if gfortran is built to use a __builtin_* function, then there is
> no way to disable this in favor of a library function.  This then means
> that the TARGET_* don't apply to gfortran unless the TARGET_* disable
> the building of the __builtin_* functions and gfortran is updated to
> honor these macros.

I don't understand.  What I propose to do is adding the sincos builtin only
if it is available on the target.  So like

+#if TARGET_HAS_SINCOS
+   gfc_define_builtin ("__builtin_sincosl",
func_longdouble_longdoublep_longdoublep,
+                     BUILT_IN_SINCOSL, "sincosl", false);
+   gfc_define_builtin ("__builtin_sincos", func_double_doublep_doublep,
+                     BUILT_IN_SINCOS, "sincos", false);
+   gfc_define_builtin ("__builtin_sincosf", func_float_floatp_floatp,
+                     BUILT_IN_SINCOSF, "sincosf", false);
+#endif

if the sincos builtin is not available, the middle-end will not
transform sin and cos
to sincos.

> I've also lost track of what needs to be reviewed for the fortran
> change due to its dependence on non-fortran changes.  Do you have
> a new patch or a pointer to the fortran changes?

I don't have an updated patch with the target macro added, but will produce one
(if this really is an issue).  But maybe sincos is practically
available everywhere
and we can ignore this issue completely.

The original patch this thread is about is at

http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00500.html

it addresses also the fact that cbrt() (a C99 function) is not
available, so we don't
transform x**(1d./3d.) to cbrt(x) for fortran.  Am I correct that
gfortran assumes
TARGET_C99_FUNCTIONS?

Thanks,
Richard.