compiler-optimization

When working with arbitrary precision arithmetic (e.g. 512-bit integers), is there any way to get GCC to use ADC and similar instructions without using inline assembly? A first glance at GMP's sourcecode shows that they simply have assembly implementations for every supported platform. Here is the test code I wrote, which adds two 128-bit numbers from the command line and prints the result. (Inspired by mini-gmp's add_n): #include <stdio.h> #include <stdint.h> #include <stdlib.h> int main (int argc, char **argv) { uint32_t a[4]; uint32_t b[4]; uint32_t c[4]; uint32_t carry = 0; for (int i = 0;

Consider this snippet: void foo(const int&); int bar(); int test1() { int x = bar(); int y = x; foo(x); return x - y; } int test2() { const int x = bar(); const int y = x; foo(x); return x - y; } In my understanding of the standard, neither x nor y are allowed to be changed by foo in test2 , whereas they could be changed by foo in test1 (with e.g. a const_cast to remove const from the const int& because the referenced objects aren't actually const in test1 ). Now, neither gcc nor clang nor MSVC seem to optimize test2 to foo(bar()); return 0; , and I can understand that they do not want to

We have been discussing this topic today at work, and none of us could come up with a definitive answer about that question. Consider the following situation: int foo() { int err; err = some_call(1); if (err != 0) return err; err = some_call(2); if (err != 0) return err; err = some_call(3); if (err != 0) return err; err = some_call(4); if (err != 0) return err; bar(); return err; } There is a lot of code repetition. Obviously, this could be factorized with a macro, sadly not with a template (because of the return clause). Or at least not directly. Now the question is, if we were to replace

Will the C++ linker automatically inline "pass-through" functions, which are NOT defined in the header, and NOT explicitly requested to be "inlined" through the inline keyword? For example, the following happens so often , and should always benefit from "inlining", that it seems every compiler vendor should have "automatically" handled it through "inlining" through the linker (in those cases where it is possible): //FILE: MyA.hpp class MyA { public: int foo(void) const; }; //FILE: MyB.hpp class MyB { private: MyA my_a_; public: int foo(void) const; }; //FILE: MyB.cpp // PLEASE SAY THIS

I've often noticed gcc converting multiplications into shifts in the executable. Something similar might happen when multiplying an int and a float . For example, 2 * f , might simply increment the exponent of f by 1, saving some cycles. Do the compilers, perhaps if one requests them to do so (e.g. via -ffast-math ), in general, do it? Are compilers generally smart enough to do this, or do I need to do this myself using the scalb*() or ldexp()/frexp() function family? For example, 2 * f, might simply increment the exponent of f by 1, saving some cycles. This simply isn't true. First you have

I played around with Godbolt's CompilerExplorer. I wanted to see how good certain optimizations are. My minimum working example is: #include <vector> int foo() { std::vector<int> v {1, 2, 3, 4, 5}; return v[4]; } The generated assembler (by clang 5.0.0, -O2 -std=c++14): foo(): # @foo() push rax mov edi, 20 call operator new(unsigned long) mov rdi, rax call operator delete(void*) mov eax, 5 pop rcx ret As one can see, clang knows the answer, but does quite a lot of stuff before returning. It seems to my that even the vector is created, because of "operator new/delete". Can anyone explain to me