Push Ifs Up And Fors Down - eviltoast
  • lysdexic@programming.devOP
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    2
    ·
    1 year ago

    I’m reasonably sure compilers can shift the if out. I believe it’s called “loop invariant code motion”.

    That scenario would only apply if the condition was constant and specified at compile time. There’s no indication on whether var1 or var2 are compile-time constants or predicates evaluated at runtime.

    • nik9000@programming.dev
      link
      fedilink
      arrow-up
      8
      ·
      1 year ago

      I don’t believe you have to specify the condition at compile time. I think that optimization would fall under dead code elimination.

      For the invariant code motion stuff the comparison just has to be invariant from start to finish. At least, that’s been my experience. The compiler will just shift the if stement.

      But, like, there are totally times when it can’t figure out that the thing is invariant. And sometimes it’s just more readable to move the if statement out of the loop.

      • lysdexic@programming.devOP
        link
        fedilink
        English
        arrow-up
        1
        arrow-down
        1
        ·
        1 year ago

        I don’t believe you have to specify the condition at compile time. I think that optimization would fall under dead code elimination.

        How do you tell if some code behind a conditional is dead if the predicate that drives the condition is evaluated at runtime?

        • nik9000@programming.dev
          link
          fedilink
          arrow-up
          4
          ·
          1 year ago

          Sorry. I wasn’t clear. If the conditional is constant a compile time you get the dead code optimization. The path not taken is removed. If it’s not constant at you may get the loop invariant movement. But only if the compiler can tell that it’s invariant.

          My point wasn’t that you should always rely on this behavior. At least, I didn’t mean to say that. I suppose what I should have said is more like “in many cases you won’t see any performance difference because the compiler will do that for you anyway.”

          I suppose I have value judgements around that like “generally you should do the thing that is more readable and let the compiler take care of stuff like moving the loop invariant”. That’s been mostly true for me. But only mostly.

          • lysdexic@programming.devOP
            link
            fedilink
            English
            arrow-up
            1
            arrow-down
            2
            ·
            edit-2
            1 year ago

            If it’s not constant at you may get the loop invariant movement. But only if the compiler can tell that it’s invariant.

            The point is that if the predicate is evaluated at runtime then the compiler plays no role because there is no compile-time constant and all code paths are deemed possible.

            I suppose what I should have said is more like “in many cases you won’t see any performance difference because the compiler will do that for you anyway.”

            I understand that you’re trying to say that compilers can leverage compile-time constants to infer if code paths are dead code or not.

            That’s just a corner case though. Your compiler has no say on what code paths are dead if you’re evaluating a predicate from, say, the response of a HTTP request. It doesn’t make sense to expect this hypothetical scenario to be realistic when you have no info on where a predicate is coming from.