[Development] How qAsConst and qExchange lead to qNN
thiago.macieira at intel.com
Wed Nov 16 19:10:18 CET 2022
On Tuesday, 15 November 2022 23:28:46 PST Marc Mutz via Development wrote:
> In the problematic case where a temporary container is created at the
> call site for the sole purpose of providing function arguments, it's
> specifically the dec, though, which is problematic (deref-to-zero has an
> acquire fence). The compiler cannot prove that the atomic hasn't been
> manipulated, so it can't optimize the deref out and go directly to
> deallocation. This includes the case of a defaulted extra argument
> (https://bugreports.qt.io/browse/QTBUG-98117), maybe not with QString,
> anymore, but, most recently, with QKeySequence (which prompted the
> addActions() revamp).
Indeed. I'd really, REALLY love to be able to inform the compiler about the
contract of reference counters and of "really const" parameter passing. I
don't know if C++ contracts would help here.
> Seeing as destruction of temps is sequenced before the end of the
> full-expression and seeing as atomics are synchronization points, the
> C++ memory model says that these atomic decs _will_ hold up execution of
> the next statements.
Partially. The CPU is slightly smarter than that and can continue to
speculatively run past the atomic operation, so long as the behaviour is as-is
to not having done so.
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
More information about the Development