News for hackers. Stuff that matters.
Re:Benchmarking JS by mraleph on Wednesday May 13, 2015 @12:36PM (#9540158)
Indeed there are some relatively well understood negative consequences to LICM and various other redundancy elimination optimizations: e.g. they increase life-time of values which can have negative impact on register allocation. Another thing is getting LICM right in the presence of conditional control flow within the loop is a non-trivial exercise, in dynamically typed languages this becomes a problem because JIT in general wants to hoist type guards aggressively but it has to account for conditional control flow to avoid weird/unnecessary deopts
Re:Benchmarking JS by DannyBee on Wednesday May 13, 2015 @01:10PM (#9540404)
Yes, LCM is pretty much a disaster in practice, and people have been trying to fix it ever since.

The set of things you are worrying about it actually precisely the set of things CLZ solves :)

Re:Benchmarking JS by mraleph on Tuesday May 19, 2015 @03:47AM (#9568588)
> The set of things you are worrying about it actually precisely the set of things CLZ solves :)

I think the set of things I worry about is slightly different, because they operate in a static environment and I operate in a dynamic one. For example, they don't seem to be worried about the transformation from:

  loop {
    if (pred) {
      // o and o.f are loop invariants
      Guard(o is X);
      v = Load(o.f);
      Use(v)
    }
  }
to

  Guard(o is X);
  v = Load(o.f);
  loop {
    if (pred) {
      Use(v)
    }
  }
this tranformation might or might not be "beneficial" depending on relation between predicate and the guard - e.g. it can lead to a code which will just deoptimize on the guard before entering the loop. There is no way of knowing this statically, so you just have to take a bet (unless you have clear indications that guard will fail when hoisted) and then undo your decision later.