On Sat, 28 Mar 2026, Richard Sandiford wrote:
> Richard Biener <[email protected]> writes:
> > The following adds a skeleton for documenting internal function details.
> > Without such a place it's quite difficult to tell people to document
> > things when they add new internal functions. We might want to split
> > the table into two, separating direct internal functions from others.
>
> Yeah, agree that separating them sounds good. The original idea for direct
> internal functions was that they would be simple wrappers around optabs,
> which are documented in md.texi. Using references to md.texi sounds
> better than trying to duplicate each entry.
>
> But there are now some direct internal functions for which the optab
> mapping is less than obvious. I suppose useful information for direct
> ifns would be:
>
> - a sample call, just to establish names, e.g. "res = foo(a, b)"
> - the underlying optab
> - where the modes of the optab come from
> - the operands to the optab, possibly using pseudo functions to
> process things like pointer/type pairs
> - which arguments are constant
>
> Although that sounds more like a json file. Not sure how easy
> it would be to present in texinfo...
We could do like tm.texi.in and have some auto-generated parts. I
was also wondering whether we can have internal-fn.def entries like
DEF_INTERNAL_FN (GOMP_DISPATCH, ECF_LEAF | ECF_NOTHROW, NULL,
"name-of-arg0", "name-of-arg1", ...)
so that we could dump internal function calls as
_1 = .GOMP_DISPATCH (/* name-of-arg0 = */ _2, ...);
but this would be more work.
The above example also shows a third class of internal functions,
those never expanded but lowered at some point.
I'm thinking of doing a complete dump of all internal functions we have,
leaving out the actual documentation but establishing the "class".
There's some grouping that can be done to avoid repetitive documentation
at least.
Richard.
