[Development] What's Q_PRIMITIVE_TYPE for?

Giuseppe D'Angelo giuseppe.dangelo at kdab.com
Tue Nov 10 20:00:09 CET 2020


On 10/11/2020 18:27, Andrei Golubev wrote:
> There's another subtle case when your type has in-class member 
> initializers - or whatever the name is - thus it's not primitive but it 
> really could/should be and you want it to be: 
> https://gcc.godbolt.org/z/3TP83f. This is something I accidentally 
> discovered.

Yes, sure. But also something like QStringView, which is (char16_t*, 
qsizetype), is a primitive type (assuming all-0 representation for a 
null pointer).

I'd stay away from classification using std:: type traits, as we want 
something that cannot automatically be inferred from compilers:
in the general case, a compiler cannot know that default construction = 
memset to 0 (e.g. out of line constructor); and certainly they cannot 
know about relocatability.

>     And I don't think that compilers are smart enough already to turn a for
>     loop that is filling with zeros into a memset, so we need the type info
>     for this. Or am I wrong?
> When profiling, memcpy/memmove resulted into an AVX-based function call 
> to some internal library function, memset might as well be similar (but 
> not sure).
> NB: for Movable types, we do not simply memset everything to zero, we 
> call placement-new. It's not quite the same as what QPodArrayOps are 
> doing, I believe.

Yes, a movable non-primitive type implies that default (value) 
construction does not set to a 0 bit pattern.

My observation was that we still need the trait because compilers don't 
seem to optimize bulk-construction of primitive types, not even if 
they're fully inline.

> https://gcc.godbolt.org/z/h5M6er

On the other hand, trivial destruction is already optimized:

> https://gcc.godbolt.org/z/dTPsbW

(This gives us some leeway to stop detecting isComplex in destruction 
paths, and just go with std::destroy unconditionally, simplifying our code.)


Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20201110/4eb9ce8c/attachment.bin>

More information about the Development mailing list