[m-rev.] for review: pragma input_spec

[Zoltan Somogyi]

On Mon, 17 Aug 2026 21:27:23 +1000, Julien Fischer <juliensf at gmail.com> wrote:
> > Proposal to fix the interaction of input_spec pragmas
> > with other pragmas that refer to specific procedures
> >
> > ------------------------------------------------------------------
> >
> > These other pragmas can be put into these groups:
> >
> >     group 1:
> >     termination
> >     termination2
> >     require_tail_rec
> 
> Termination analysis has three:
> 
>    terminates
>    termination_info
>    termination2_info

terminates does not refer to specific procedures; it applies
to a whole predicate (or function). (Maybe it *should* refer
to procedures, but at the moment, it does not.)

> (We do allow the latter two outside of .opt and .trans_opt files, although I
> can't remember anyone actually ever doing that.)

I believe the library has some.

> We also have:
> 
>     :- pragma promise_pure
>     :- pramga promise_semipure
>     :- pragma format_call
>     :- pragma consider_used
>     :- pragma inline
>     :- pragma no_inline
>     :- pragma no_determinism_warning

Again, all of those refer to whole predicates, not procedures.

> And as mentioned earlier in this thread :- pragma foreign_export.

I did leave that one out, but it can be implemented by using the
current proc id to original proc id mapping I proposed.

> > GROUP 1
> >
> > The pragmas in group 1 each call for some diagnostic about the procedure
> > if some condition is not met. Duplicating the procedure will indirectly
> > cause the duplication of these diagnostics as well, but this is not an
> > issue if the diagnostics for each duplicate proc are identical to the
> > diagnostics for the original procedure. However, the diagnostic text
> > may include the argument modes, and these WILL differ in the duplicated
> > copies.
> >
> > The way I propose to fix this is as follows.
> >
> > - When input specialization duplicates a procedure, mark the duplicate
> >   proc_info as being a duplicate created by input specialization.
> >
> > - When compiler passes that the generate diagnostics called for by
> >   the pragmas in group 1, simply to do not process the procedures
> >   marked in that way.
> >
> > - To ensure that all called-for diagnostics are in fact generated,
> >   keep the original procedure in its pred_info's proc_table EVEN WITH
> >   REPLACE_IN_MODE.
> >
> > - To ensure the absence of calls to any procedures that replace_in_mode
> >   logically deletes, mark each original procedure that input specialization
> >   creates duplicates of as either "original, logically deleted" (with
> >   replace_in_mode) or as "original, logically kept" (with add_to_in_mode),
> >   and
> >
> > - have simplification generate an error for each call to an "original,
> >   logically deleted" procedure, in roughly the same way as we generate
> >   warnings for calls to obsolete predicates.
> >
> > In general, this new notation could be a new field in proc_infos,
> > whose type is something like this:
> >
> > :- type maybe_input_spec_proc
> >     --->    not_involved_in_input_spec(proc_id)
> >     ;       input_spec_original_proc_kept(proc_id)
> >     ;       input_spec_original_proc_deleted(proc_id)
> >     ;       input_specialized_proc(proc_id).
> >
> > The proc_id fields would each id the *original* procedure
> > that the annotated procedure is a (possibly modified) copy of.
> 
> ...

Sorry, but I don't understand what that is supposed to mean.

> > GROUP 4
> >
> > It has been a *very* long time since I looked at the code that
> > implements structure sharing/reuse pragmas. I don't know enough
> > to say how they should be handled. I don't even know whether
> > they work well enough for it to be worth worrying about
> > how they would be affected.
> 
> It has been a very long time since *anyone* looked at it.
> I suggest simply disabling input specialization if --ctgc is enabled.
> (That should be sufficient for anyone who picks up the work CTGC.
> If that work is ever picked up, then we can worry about its
> interaction with input specialization.)

Will do.

Thanks for the review.

Zoltan.