[Development] How qAsConst and qExchange lead to qNN

[Thiago Macieira]

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