https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125672

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
So it's

  if (_159 == -1)
    goto <bb 5>; [41.00%]
  else
    goto <bb 4>; [59.00%]

  <bb 4> [local count: 563821836]:

  <bb 5> [local count: 955630224]:
  # iftmp.16_203 = PHI <_221(3), _242(4)>
  if (_125 == -1)
    goto <bb 7>; [41.00%]
  else
    goto <bb 6>; [59.00%]

  <bb 6> [local count: 563821836]:

  <bb 7> [local count: 955630224]:
  # iftmp.17_202 = PHI <_226(5), _247(6)>
  if (_134 == -1)
    goto <bb 9>; [41.00%]
  else
    goto <bb 8>; [59.00%]

  <bb 8> [local count: 563821836]:

  <bb 9> [local count: 955630224]:
  # iftmp.18_201 = PHI <_231(7), _252(8)>
  if (_119 == -1)
    goto <bb 11>; [41.00%]
  else
    goto <bb 10>; [59.00%]

  <bb 10> [local count: 563821836]:

  <bb 11> [local count: 955630224]:
  # iftmp.19_200 = PHI <_236(9), _257(10)>
  if (_159 == -1)
    goto <bb 13>; [41.00%]
  else
    goto <bb 12>; [59.00%]

  <bb 12> [local count: 563821836]:

  <bb 13> [local count: 955630224]:
  # iftmp.20_187 = PHI <_56(11), _60(12)>
  if (_125 == -1)
    goto <bb 15>; [41.00%]
  else
    goto <bb 14>; [59.00%]

  <bb 14> [local count: 563821836]:

  <bb 15> [local count: 955630224]:
  # iftmp.21_186 = PHI <_57(13), _61(14)>
  if (_134 == -1)
    goto <bb 17>; [41.00%]
  else
    goto <bb 16>; [59.00%]

  <bb 16> [local count: 563821836]:

  <bb 17> [local count: 955630224]:
  # iftmp.22_185 = PHI <_58(15), _62(16)>
  if (_119 == -1)
    goto <bb 19>; [41.00%]
  else
    goto <bb 18>; [59.00%]

  <bb 18> [local count: 563821836]:

  <bb 19> [local count: 955630224]:
  # iftmp.23_184 = PHI <_59(17), _63(18)>

which is indeed redundant chained tests.  This asks for a higher level
transform, aka re-association (and simplification) of tests.  I've always
wanted some CFG/non-CFG conditional abstraction that would allow for this
irrespective of whether we're dealing with if-combined or open-coded
conditionals.

Until we get such "CFG aware association" there's only jumpthreading
optimizing the number of runtime branches, so we can't really remove
that.

Reply via email to