Date: Sat, 20 May 2023 02:53:28 +1000
On Sat, May 20, 2023 at 1:04 AM Martin Uecker <ma.uecker_at_[hidden]> wrote:
> Am Samstag, dem 20.05.2023 um 00:53 +1000 schrieb Andrew Tomazos:
> > Changing to the concrete interpretation would render numerous existing
> practice compiler optimizations non-conformant as N3128 points out.
>
> N3128 points out the exact opposite: that we are not aware of
> any relevant compiler optimization affected by this. The only
> exception we know of are some re-ordering of volatile accesses,
> which seem undesirable and dangerous.
That was indeed a misinterpretation of the N3128 claim. The
concrete interpretation optimizations still have the usual latitude to time
travel via the as-if rule and change unobservable behaviour prior to the
undefined operation - that all optimizations have. The claim is that under
this usual latitude, almost all of those optimizations can be performed
without resorting to the more powerful assumption of the abstract
interpretation. And that an insignificant number of optimizations require
changing observable behavior prior to undefined operations.
Has the "generic argument" supporting the claim in section 3:
"In portable C code I/O is performed using function calls of the standard
library. A compiler can generally not assume that a function returns to the
caller, because the function could call ‘exit’, ‘abort’, ‘longjmp’, or
enter an infinite loop. For this reason, it is never allowed for a compiler
to use any information derived from an operation with potential UB that
comes after a function call in a way that could affect observable behavior
before the function call. Consequently, observable behavior that is
accessed via function calls (i.e. all except volatile accesses) can not be
affected by time-traveling optimizations even when using the abstract
interpretation. In principle, a compiler could use special knowledge about
C library functions and use the fact that those functions always return to
the caller, but we are not aware of any compiler which does this (and it
hardly seems worthwhile)."
been peer-reviewed by a significant number of experts? What is the status
of this paper within WG14?
The only way it seems to refute it would be to find a significant number of
counter-examples. A counter-example would be an optimized program which
admits incorrect observable behaviour prior to an undefined operation being
executed.
If the claim is verified, then it is hard to imagine a reason why WG21
wouldn't adopt it also. The concrete interpretation seems strictly better
if the underlying claim is true. That is, unless there are other benefits
of the abstract interpretation beyond optimization. N3128 does not seem to
point out any.
> Am Samstag, dem 20.05.2023 um 00:53 +1000 schrieb Andrew Tomazos:
> > Changing to the concrete interpretation would render numerous existing
> practice compiler optimizations non-conformant as N3128 points out.
>
> N3128 points out the exact opposite: that we are not aware of
> any relevant compiler optimization affected by this. The only
> exception we know of are some re-ordering of volatile accesses,
> which seem undesirable and dangerous.
That was indeed a misinterpretation of the N3128 claim. The
concrete interpretation optimizations still have the usual latitude to time
travel via the as-if rule and change unobservable behaviour prior to the
undefined operation - that all optimizations have. The claim is that under
this usual latitude, almost all of those optimizations can be performed
without resorting to the more powerful assumption of the abstract
interpretation. And that an insignificant number of optimizations require
changing observable behavior prior to undefined operations.
Has the "generic argument" supporting the claim in section 3:
"In portable C code I/O is performed using function calls of the standard
library. A compiler can generally not assume that a function returns to the
caller, because the function could call ‘exit’, ‘abort’, ‘longjmp’, or
enter an infinite loop. For this reason, it is never allowed for a compiler
to use any information derived from an operation with potential UB that
comes after a function call in a way that could affect observable behavior
before the function call. Consequently, observable behavior that is
accessed via function calls (i.e. all except volatile accesses) can not be
affected by time-traveling optimizations even when using the abstract
interpretation. In principle, a compiler could use special knowledge about
C library functions and use the fact that those functions always return to
the caller, but we are not aware of any compiler which does this (and it
hardly seems worthwhile)."
been peer-reviewed by a significant number of experts? What is the status
of this paper within WG14?
The only way it seems to refute it would be to find a significant number of
counter-examples. A counter-example would be an optimized program which
admits incorrect observable behaviour prior to an undefined operation being
executed.
If the claim is verified, then it is hard to imagine a reason why WG21
wouldn't adopt it also. The concrete interpretation seems strictly better
if the underlying claim is true. That is, unless there are other benefits
of the abstract interpretation beyond optimization. N3128 does not seem to
point out any.
Received on 2023-05-19 16:53:42