Date: Tue, 11 Aug 2020 20:45:48 +0200
Martin,
on Tue, 11 Aug 2020 16:12:24 +0000 you ("Uecker, Martin"
<Martin.Uecker_at_[hidden]>) wrote:
> Am Dienstag, den 11.08.2020, 17:31 +0200 schrieb Jens Gustedt via
> Liaison:
> > Niall,
> >
> > on Tue, 11 Aug 2020 15:46:07 +0100 you (Niall Douglas via Liaison
> > <liaison_at_[hidden]>) wrote:
> >
> > > On 11/08/2020 13:26, Jens Gustedt via Liaison wrote:
> [...]
> > >
> > > I was, quite literally, just about to give the same feedback.
> > > ...
> >
> > Since I am not sure that I understood if you were pro or against
> > using that function type for labels.
> >
> > My argument is that a label is not a function entry point, and so we
> > should never use a function pointer type for this, be the function
> > type beneath how ever it may. The mechanics of function call don't
> > apply, and the `noreturn` would mean very different things for
> > labels than for function calls.
>
> I wonder why you think this is the case?
From a purely practical point of view. If I look into the assembler
that a function call produces and for a `goto`, the sequences that are
produced are different. Even if a function call does not receive
arguments, it poses constraints on registers, some of them are saved
perhaps, etc. Two relatively distinct things that are not ABI
compatible.
Also, a `noreturn` function is something completely different
here. When calling a `noreturn` function my compiler knows that the
state of that calling function (maybe besides jump buffers) can be
scrapped, and the code can be optimized towards this. Some stores can be
removed, for example. A `goto` just instructs that code after that is
unreachable, end of lifetime decisions for variables need flow
analysis beyond the `goto`.
> From a theoretical
> point of view, as well as from practical experience, I do not
> see why a function that does not return and a target of
> goto could not be treated in the same way. Tail calls are
> also often compiled into jumps.
The fact that under certain circumstances one construct can be
replaced by the other, even automatically, does not prove that they
are equivalent in all cases.
> Actually, it would be nice to require a 'goto' to call
> this special non-returning functions... I would like to see
> such calls marked clearly in the code.
That would be inventing another language or dialect. (Basic had that,
no?)
> (I am also ok with label_t as this a risk-free design).
I am still not sure that I want it at all. Also we have heard quite
contrasting views for C++ on that matter. One that that this would be
great to speed up some application, and another one that this is
merely peripheral for C++ with the risk of being eliminated
completely.
Jens
on Tue, 11 Aug 2020 16:12:24 +0000 you ("Uecker, Martin"
<Martin.Uecker_at_[hidden]>) wrote:
> Am Dienstag, den 11.08.2020, 17:31 +0200 schrieb Jens Gustedt via
> Liaison:
> > Niall,
> >
> > on Tue, 11 Aug 2020 15:46:07 +0100 you (Niall Douglas via Liaison
> > <liaison_at_[hidden]>) wrote:
> >
> > > On 11/08/2020 13:26, Jens Gustedt via Liaison wrote:
> [...]
> > >
> > > I was, quite literally, just about to give the same feedback.
> > > ...
> >
> > Since I am not sure that I understood if you were pro or against
> > using that function type for labels.
> >
> > My argument is that a label is not a function entry point, and so we
> > should never use a function pointer type for this, be the function
> > type beneath how ever it may. The mechanics of function call don't
> > apply, and the `noreturn` would mean very different things for
> > labels than for function calls.
>
> I wonder why you think this is the case?
From a purely practical point of view. If I look into the assembler
that a function call produces and for a `goto`, the sequences that are
produced are different. Even if a function call does not receive
arguments, it poses constraints on registers, some of them are saved
perhaps, etc. Two relatively distinct things that are not ABI
compatible.
Also, a `noreturn` function is something completely different
here. When calling a `noreturn` function my compiler knows that the
state of that calling function (maybe besides jump buffers) can be
scrapped, and the code can be optimized towards this. Some stores can be
removed, for example. A `goto` just instructs that code after that is
unreachable, end of lifetime decisions for variables need flow
analysis beyond the `goto`.
> From a theoretical
> point of view, as well as from practical experience, I do not
> see why a function that does not return and a target of
> goto could not be treated in the same way. Tail calls are
> also often compiled into jumps.
The fact that under certain circumstances one construct can be
replaced by the other, even automatically, does not prove that they
are equivalent in all cases.
> Actually, it would be nice to require a 'goto' to call
> this special non-returning functions... I would like to see
> such calls marked clearly in the code.
That would be inventing another language or dialect. (Basic had that,
no?)
> (I am also ok with label_t as this a risk-free design).
I am still not sure that I want it at all. Also we have heard quite
contrasting views for C++ on that matter. One that that this would be
great to speed up some application, and another one that this is
merely peripheral for C++ with the risk of being eliminated
completely.
Jens
-- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Received on 2020-08-11 13:49:30