Yes, you're right. Since we evaluate all comparisons in order and do not (yet) use any information about whether a comparison was ever true (i.e. the case-clause executed or not), we can't end in the scenario I described.
So never mind my suggestion for now, because it only works if we know that a case-block was never executed. 14. dec. 2010 20.16 skrev <[email protected]>: > > http://codereview.chromium.org/5812005/diff/1/src/hydrogen.cc > File src/hydrogen.cc (right): > > http://codereview.chromium.org/5812005/diff/1/src/hydrogen.cc#newcode2656 > src/hydrogen.cc:2656: last_false_block->Finish(new HDeoptimize); > On 2010/12/14 16:03:17, fschneider wrote: >> >> It is safe to deoptimize after the last smi-compare, but it seems > > overly >> >> restricting, if there are reachable smi-compares afterwards. e.g. > >> switch(x) { >> case 0: A(); break; >> case 1: B(); break; >> default: C(); break; >> } > >> If the inputs are only 0 and 2 we would deoptimize after the first > > smi-compare >> >> with 0, and not optimize the default-clause. > > When 2 is given we have to test all comparisons so they all will be > reached (provided your type feedback change is in), and we'll get the > expected optimized code. As long as the full codegen emits case > comparisons in sequence without trying to be smart, we won't get into > the situation you describe. > > http://codereview.chromium.org/5812005/ > -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
