Showing posts with label cpp20_optimize. Show all posts
Showing posts with label cpp20_optimize. Show all posts

Jun 2, 2022

[compiler][optimization] jump threading optimizations intro

Reference:
A gentle introduction to jump threading optimizations
https://developers.redhat.com/blog/2019/03/13/intro-jump-threading-optimizations

cmove:
https://stackoverflow.com/questions/30150274/purpose-of-cmove-instruction-in-x86-assembly


Code duplication is the key for the optimization trade-off.



gcc options:
  • --param max-fsm-paths-insns=500
  • --param max-fsm-thread-length
  • -fno-thread-jumps
  • -fdump-tree-all-details -O2

code in action

example 1
if (a > 5)
    goto j;
  stuff ();
  stuff ();
j:
  goto somewhere;
to
if (a > 5)
    goto somewhere;
  stuff ();
  stuff ();
j:
  goto somewhere;

example 2
void foo(int a, int b, int c)
{
  if (a && b)
    foo ();
  if (b || c)
    bar ();
}
to
void foo(int a, int b, int c)
{
  if (a && b) {
    foo ();
    goto skip;
  }
  if (b || c) {
skip:
    bar ();
  }
}

example 3
void foo(int a, int b, int c)
{
  if (a && b)
    foo ();
  tweak ();
  if (b || c)
  bar ();
}
to
void foo(int a, int b, int c)
{
  if (a && b) {
    foo ();
    tweak ();
    goto skip;
  }
  tweak ();
  if (b || c) {
skip:
    bar ();
  }
}

Nov 28, 2018

[C++][cppcon 2018] std::basic_string: for more than just text - Brian Ruth


This could be one of the most interesting/hacking videos in cppcon 2018 :-D

std::basic_string can be the container other then 'char'-ish type.
i.e int, bool, UDT etc.

And, it applies SSO on those types as well, thus we might ask, why vector
doesn't have SSO?
Well, we do have in LLVM:
SmallVector.h
or Boost's:
small_vector

And we might have 'relocatable' in C++20 iff vector contains type that meets Rule Of Zero.



Nov 27, 2018

[C++][cppconf 2018] "Trivially Relocatable" Arthur O'Dwyer



Definition:
iff a move constructor and a destructor are non-trivial in pair,
the result is tantamount to 'memcpy', thus defined by Arthur as 'relocatable'.

e.g std::shared_ptr

Thus, in compiler, can't we just do a 'memcpy' instead of following
the language syntax doing a move construct + destruct?
Yes, we can!


Reference:
https://quuxplusone.github.io/blog/2018/07/18/announcing-trivially-relocatable/
https://www.youtube.com/watch?v=8u5Qi4FgTP8

assembly: call vs. callq
https://stackoverflow.com/a/46753525
quote:
It's just 'call'. Use Intel-syntax disassembly if you want to be able to look up instructions in the Intel/AMD manuals.

The q operand-size suffix does technically apply (it pushes a 64-bit return address and treats RIP as a 64-bit register), but there's no way to override it with instruction prefixes.
i.e. calll and callw aren't encodeable in 64-bit mode, so it's just annoying that some AT&T syntax tools show it as callq instead of call. This of course applies to retq as well.


Is this new?
nope :-)
In Lippman's Inside the C++ Object Model mentioned that inside the copy constructor
we could use system call memcpy to speed up the bit-wise copy; however, there's a gotcha, which is  object slice, which could accidentally copy the derived object's v-ptr.
In Arthur's proposal, we modify compiler(not run-time), implement the memcpy directly when
the type has Rule Of Zero trait.
C++ core quideline: C.20: If you can avoid defining default operations, do
C++ core guideline: C.67: A polymorphic class should suppress copying