Gosh, I really wish GCC had more/better documentation. Especially big picture stuff.
E.g., I would like to know what register allocation algorithms it uses (and how certain details are handled), but looking at that code I noped out...
https://gcc.gnu.org/onlinedocs/gccint/RTL-passes.html
There's really quite a lot of documentation and published papers when you actually look:
https://github.com/gcc-mirror/gcc/blob/751f306688508b08842d0...
GCC: Lots of documentation for backend authors, actively made difficult to being used for frontends for many years (although things have improved dramatically)
GCC’s code style is strange because the original authors wanted to make it look like Lisp for some reason.
While gcc (and in general compiler) plugins are some of the most interesting tech enablers (be it for fuzzing,, static analysis, or runtime checks injection) 'People competently maintaining gcc plugins' (a sect I'm not a part anymore, thank dog) are amongst the most patient, devoted, unsung angels of this world.
It’s also garbage collected so it’s still not “normal” C++ but neither is LLVM.
Not sure about the plugin API, but C++ is basically impossible to use with plugins because it’s so hard to keep ABI contracts, so it might not have changed.
And I’ve seen _p and friends all over the place usually to differentiate between a pointer and, umm, not pointer. I thought it was a C++ism to be honest.
p is short for predicate.
However, when the discussion already mentions "ABI contracts", they're probably referring specifically to the "fragile binary interface problem" (especially regarding member field access), which does not affect all languages that offer inheritance.
As the Wikipedia article mentions, this more specific problem is (confusingly) often referred to just as the "fragile base class problem".
https://en.wikipedia.org/wiki/Fragile_binary_interface_probl...
(It pays for this with extra indirection at runtime, of course: ivar accesses must first look up their runtime-resolved offset.)
Whether that was a good plan is up for debate, but there you go.
I'm wondering why you'd like to know. If it is just for your curiosity, that's very good. If you want to participate in the compiler development effort, hat tip!
But if you are thinking about tuning your code to such an internal detail, please don't! Coding to an implementation, rather than an interface, is never a good idea.