This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: BUILT_IN_FRONTEND - how did this work?


Steven Bosscher <stevenb.gcc@gmail.com> writes:

> It seems that there once was support for builtin functions defined by
> a front end. This is still a useful idea (see e.g. PR24777) but it
> looks like there are no frontend built-in functions anymore. At least,
> a grep for BUILT_IN_FRONTEND gives no meaningful results. There's a
> hint that it may have worked, long ago, in ChangeLog-2000. But there
> is no documentation whatsoever about how BUILT_IN_FRONTEND is supposed
> to work.
>
> Does anyone know how BUILT_IN_FRONTEND should work, what one has to do
> to define a front-end built-in function? Examples? Any idea if there
> ever was a front end that used this feature?

It worked by using a langhook to expand the BUILT_IN_FRONTEND function
to RTL.  But that was only meaningful if you could pass language
specific trees to expand_expr.  That capability was dropped when
tree-ssa came in; language specific trees were converted to GENERIC
rather than to RTL.

BUILT_IN_FRONTEND no longer makes much sense.  We would now instead say
that the frontend should generate appropriate GENERIC for the builtin
function.  In the current world frontends don't generate RTL directly.

BUILT_IN_FRONTEND was used for printf for a while.  That usage was
removed in http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02011.html .

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]