Understanding GCC Builtins to Develop Better Tools [pdf]

https://www.manuelrigger.at/papers/GCCBuiltins-ESECFSE19-preprint.pdf

by mpweiher • 7 years ago

57 12 7 years ago

teddyh• 7 years ago

Not a builtin, but a GCC feature which has improved my C code hugely is __attribute__((cleanup)). It is used to specify a destructor for a local variable; when the variable goes out of scope the function is called with a pointer to the variable as an argument.

Example:

  {
    __attribute__((cleanup(foo)))
      int a;
      …
     /* foo(&a) will implicitly be called here */
  }

therein• 7 years ago

Didn't know this existed. The closest thing I can think of similar to this is `defer` of Golang.

jart5• 7 years ago

It'd be great if the GCC devs adopted a process for introducing new builtins, that required code review, unit testing, and justification of use-cases.

Some of the GCC builtin wrappers are outstanding, e.g. __builtin_memcpy on two-power sizes, since it can do things that wouldn't be possible otherwise.

Some GCC builtins, e.g. __builtin_va_start, can take away flexibility since it locks into the core codebase nontrivial code generation that's suboptimal in certain cases.

Most of the builtins are neutral, e.g. atomics api, which provides 42 different ways to say asm("mov"), 13 different ways to say asm("xchg"), and twenty different ways to asm("lock cmpxchg").

Other GCC builtins, e.g. __builtin_ia32_rdrand32_step, don't even have the multi-architecture benefit, only seem to exist because some folks disagree with the asm() keyword, and is naturally problematic from a security standpoint when the GCC devs get it wrong.

What's great about builtins like asm() is it's one simple general-purpose abstraction that puts the power of so many compiler internals into the hands of the user at once, rather than being another narrowly-focused case-by-case feature you need to beseech the core dev team to get.

earenndil• 7 years ago

The main problem with assembly, afaik, is that gcc doesn't know how to optimize even very simple assembly.

canarypilot2• 7 years ago

GCC treats inline assembly as an opaque blob of text It knows nothing about, plus some register constraints it knows something about. It will “optimise” assembly if you’ve passed the right registers as input/output, and haven’t marked it volatile and memory clobbering. Simple things like eliminating it if it is dead code, but this probably isn’t the optimisation you were looking for!

Depending on who you ask, this is a feature, not a defect. Inline assembly is your last line of defence against a compiler which thinks it knows better than you.

Clang/llvm go a step further and do parse and optimize your inline assembly; that makes me uncomfortable, but I’ve always subscribed to the “don’t touch user asm” mindset for compiler development.

Your main benefit of builtins over assembly is that no matter how hard I tried I couldn’t get the suggested replacement given by the parent for __atomic_compare_exchange to assemble on my arm64 server!

jart5• 7 years ago

If GCC has a correctly defined DAG of asm() statements, it might not be able to apply things like De Morgan's Law, but it can do a lot.

Usually what gets optimized the most, counter-intuitively, is the adjacent code that the compiler generates itself, rather than the handwritten assembly you supply (which can in fact be empty string). This basically gives you a means of controlling the compiler's internal algorithms for performing register allocation.

Take for example foo(). If that were written as asm() it'd imply asm("call foo" ::: rax, rcx, rdx, r8, r9, r10, r11, r12, xmm0, xmm1, etc.). If you know ahead of time that foo won't clobber those million different things, then explicitly using asm() can have a wild impact. I've seen just one of those alone cut down the code size of large functions by a third.

bonzini• 7 years ago

It'd be great if the GCC devs adopted a process for introducing new builtins, that required code review, unit testing, and justification of use-cases

I am not sure how your suggestion differs from how GCC is already being developed.

TazeTSchnitzel• 7 years ago

It surprises me more of these haven't become standardised features. __builtin_expect is very common (but as a compiler hint I somewhat understand its absence), __builtin_clz is arguably a missing feature.

jart5• 7 years ago

I suspect (but haven't verified) that modern compilers are actually implementing __builtin_expect() as a no-op. Much better alternatives exist today, e.g. GCC 8+ __cold__ and profile guided optimizations, which don't have a negative impact on code readability.

Understanding GCC Builtins to Develop Better Tools [pdf]

Related Stories