[PATCH] D60295: [SelectionDAG] Change the jump table size unit from entry to target

[Hans Wennborg via Phabricator via llvm-commits]

hans added a comment.

In D60295#1472786 <https://reviews.llvm.org/D60295#1472786>, @evandro wrote:

> In D60295#1462585 <https://reviews.llvm.org/D60295#1462585>, @hans wrote:
>
> > I still think looking at the number of cases isn't that much better than looking at the size of the range though. As you said, the point is to limit the load on the branch target predictor, and IIUC that's limited on the number of *different branch targets*, which is really orthogonal to the number of cases. I realize that we don't have that information as readily available, but do you agree that limiting the jump table to a certain number of different targets would be a better approach?
>
>
> For each case there is a target in the table, that may potentially be reached or not at run time, but would prevent stressing the predictor.  So, cases and targets are not orthogonal, but the same.


But if that's so, shouldn't the "default" cases count too?

I don't know how CPUs do this internally, but in your change description you wrote: "Rather, branch predictors typically use resources limited by the number of actual targets that occur at run time."

I interpreted this as the number of actual target addresses, which is less than or equal to the number of cases. For example in

  switch (x) {
  case 1: case 8: case 12: foo(); break;
  case 3: case 7: case 9: bar(); break;
  default: baz();
  }

there are only 3 branch targets, but 6 cases, and an indirect jump through a jump table could take 12 different values.

The question is which of those dimensions that the branch target predictor is limited by.

Does the CPU keep track of the branch target for each of the 12 possible in-range values? Or does it have some kind of reverse map that tracks which values map to which of the 3 targets? I don't have the expertise to answer this, but so far I'm not convinced that limiting the number of cases is better than limiting the size of the range.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60295/new/

https://reviews.llvm.org/D60295