C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Every variable is volatile, everything is laundered, no optimisation

From: Lénárd Szolnoki <cpp_at_[hidden]>
Date: Fri, 25 Aug 2023 22:01:48 +0100
On Fri, 2023-08-25 at 16:24 -0400, Brian Bi via Std-Proposals wrote:
> On Fri, Aug 25, 2023 at 5:24 AM Frederick Virchanza Gotham via Std-
> Proposals <std-proposals_at_[hidden]> wrote:
> > I've occasionally seen people use the compiler switch "-O0" with
> > the
> > GNU compiler and also with LLVM.
> >
> > What if we had a standardised way of marking a function as
> > 'verbose'
> > to tell the compiler:
> > (1) All objects are to be treated as 'volatile'
> > (2) All pointers are automatically std::launder'ed
> > (3) No shortcuts are taken for aliasing
> >
>
>
> Note that these are actually two different kinds of changes. (2) and
> (3) have the potential to give the program defined behaviour if it
> otherwise would have had undefined behaviour. On the other hand, in
> (1) I assume that you do not actually want to change the types for
> the purpose of semantic analysis (e.g., if you call a method on the
> object, you wouldn't want it to implicitly call the volatile-
> qualified overload) and you just want to disable certain
> optimizations. In that case, you do not need the standard, you just
> need to convince your compiler vendor to add an attribute that you
> could slap on the function in order to tell the compiler to disable
> those optimizations.
>
> As for (2) and (3), I personally think that there is value in
> providing a way to opt out of certain forms of UB that have no
> purpose other than to let the optimizer make extra assumptions, but
> it is not clear whether the idea of controlling it on a per-function
> basis is coherent. GCC has -fno-strict-aliasing, which you can
> control only per translation, not per function;

GCC does have a per-function fine-grained optimisation attribute. In
theory it could accept "no-strict-aliasing" too, but I don't know if
it's actually supported. However the docs say that "the optimize
attribute should be used for debugging purposes only. It is not
suitable in production code."

https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html

> perhaps that is good enough already? If I were you, I would talk to
> the GCC folks and find out more about how that flag works, and to
> what extent it's possible to link together two different TUs where
> one of them was translated with the flag and the other was not, and
> other important details like that, and whether they see any obvious
> specification issues with trying to standardize such a flag (perhaps
> in the form of a new type of declaration that must occur at the
> beginning of a translation unit before any declarations of objects,
> functions, or classes).
>
> >
> > Something like as follows:
> >
> > void Func(int *const p, double *const q) __verbose
> > {
> > *p = 0;
> > *q = 67.5;
> > if ( *p ) DoSomething();
> > }
> >
> > In the above function, normally the 'if' statement would be removed
> > by
> > the optimiser. But since the function is marked as 'verbose', the
> > two
> > pointers 'p' and 'q' are treated as pointing to volatile, and also
> > there's no anti-aliasing assumption between 'p' and 'q'.

Received on 2023-08-25 21:01:52