fixing build!

fixing build?

getting rid of unneeded logs

In rG76029cc53e838e6d86b13b0c39152f474fb09263#1104327, @yota9 wrote:

Hello, this patch is important for golang support and was submitted without a review :( We need to decide how to fix the problem (if any, since I didn't see one) and fix it, but not revert the patch..

rebase

updated comments per review

We reviewed the code internally prior sending upstream, and it is still looks good to me.

rebase + a small adjustment of the default optimization flags

In D123050#3454138, @tschuett wrote:

There was a *very* brief discussion about system models on llvm-dev. Did you consider using something similar in bolt resp. llvm?
https://lists.llvm.org/pipermail/llvm-dev/2018-October/127319.html

rebase

reformat

In D121921#3396378, @yota9 wrote:

@spupyrev I don't see strict rules about the else/eslse if statement indeed. This is clearly personal preference, I hust don't like the idea of extra nesting where you can go without it. As for my personal experience LLVM tries to eliminate extra nesting where it is possible. But speaking of the new variant - I think you need to add braces for "else if " statement, since in coding style https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements there are some words about the if/else statement to be uniform e.g.

// Use braces for the `if` block to keep it uniform with the else block.
if (isa<FunctionDecl>(D)) {
  handleFunctionDecl(D);
} else {
  // In this else case, it is necessary that we explain the situation with this
  // surprisingly long comment, so it would be unclear without the braces whether
  // the following statement is in the scope of the `if`.
  handleOtherDecl(D);
}

@yota9 please let me know if I got your suggestion right.
Also would be great to understand the motivation for the suggested change; I actually
like the earlier version more, as it shows the two conditions symmetrically (but that
might be just a personal preference)

adding a test

added back the option for overwriting entry count (ON by default)

modifying island connectors + removed one (controversial) option

update broken test

rebase

sorry misspelled increase/decrease

rename

minor

faster convergence

review comments

Detailed perf measurements on clang, release_10 (speedups over the previous version of inference):
with CSSPGO+LTO:

benchmark1: 1.52% (stat sig)
benchmark2: 0.84% (stat sig)

with AutoFDO+LTO:

benchmark1: 1.72% (stat sig)
benchmark2: 0.61% (stat sig)

rebase

rebase

addressing hoy's comments

In D116970#3236061, @wenlei wrote:

I see up to 0.5% perf on some (large) binaries, e.g., clang-10 and gcc-8.

Great results! And the change also makes sense. Was this with AutoFDO or CSSPGO or InstrPGO? How does overall count quality look with this change?

We can also give it a try on server workloads.

another clang-format

git-clang-format HEAD^

rebase

making the tests deterministic

changed type of Chain.Id to uint64