1. 10

  2. 3

    And, I really think that if a commercial ICC compiler can generate perfect code for this case, GCC and clang should be able to do it too, because these are compilers that I use daily…

    Let’s not forget that ICC is much more specific than either of GCC and Clang/LLVM, so it can expend a lot more effort to catch these things.

    Regardless, the reasoning behind this statement leaves a lot to be desired.

    It’s unclear to me if the metric the author was concerned with was size or speed. Presumably size since there was no measurements given for how the code performed, aside from the (incorrect) assertion that smaller code is faster code (as evidenced by the remark, “GCC magically transformed 9 initial instructions into 37, making the code larger and slower!”).

    1. 4

      On the GCC issue he filed they’ve already determined it’s an optimizer bug.

      It is induction variable optimization (-fivopts) that re-writes the main induction variable. We have [… optimizer details …] but it doesn’t seem to account the extra cost for the exit test replacement when facing equal original/final cost.

      TL;DR: GCC is calculating costs incorrectly, and can favor inserting extra instructions to enable an iv rewrite, even when the iv rewrite won’t make a difference.

    2. 2

      Both compilers are focused on dumb micro-optimizations. That loop pattern is super common.