1. 14 Feb, 2015 5 commits
    • Kevin Modzelewski's avatar
      Merge branch 'deopt' · 2e030372
      Kevin Modzelewski authored
      Fully switch to the new deopt system, and clean up a lot of stuff.
      2e030372
    • Kevin Modzelewski's avatar
      Further distinguish OSR and non-osr compiles · 1bfb56e8
      Kevin Modzelewski authored
      A "FunctionSpecialization" object really makes no sense in the context of
      an OSR compile, since the FunctionSpecialization talks about the types
      of the input arguments, which no longer matter for OSR compiles.
      Now, their type information comes (almost) entirely from the OSREntryDescriptor,
      so in most places assert that we get exactly one or the other.
      1bfb56e8
    • Kevin Modzelewski's avatar
      Can kill all notion of partial-block-compilation · 0e60f0d3
      Kevin Modzelewski authored
      We only needed that for supporting the old deopt system
      0e60f0d3
    • Kevin Modzelewski's avatar
      Nuke the old "block guards" and the rest of the old deopt system · 8feae20e
      Kevin Modzelewski authored
      Long live new-deopt!
      8feae20e
    • Kevin Modzelewski's avatar
      For OSRs, do type analysis starting from OSR edge · ea673dfd
      Kevin Modzelewski authored
      Before we would do type analysis starting from the function entry
      (using the specialization of the previous function).  This makes things
      pretty complicated because we can infer different types than we are OSRing
      with!  Ex if the type analysis determines that we should speculate in an
      earlier BB, the types we have now might not reflect that speculation.
      
      So instead, start the type analysis starting from the BB that the OSR starts at.
      Should also have the side-benefit of requiring less type analysis work.
      
      But this should let us get rid of the OSR-entry guarding, and the rest of
      the old deopt system!
      ea673dfd
  2. 13 Feb, 2015 26 commits
  3. 12 Feb, 2015 9 commits