Skip to content
  1. Nov 06, 2010
  2. Oct 20, 2010
  3. Aug 06, 2010
  4. Jul 01, 2010
  5. Jun 25, 2010
  6. Jun 16, 2010
  7. Jun 15, 2010
  8. Jun 01, 2010
  9. May 28, 2010
  10. Apr 17, 2010
  11. Apr 16, 2010
  12. Apr 15, 2010
  13. Mar 04, 2010
  14. Jan 28, 2010
  15. Jan 21, 2010
  16. Jan 15, 2010
  17. Oct 25, 2009
  18. Oct 14, 2009
    • Duncan Sands's avatar
      I don't see any point in having both eh.selector.i32 and eh.selector.i64, · 8e6ccb65
      Duncan Sands authored
      so get rid of eh.selector.i64 and rename eh.selector.i32 to eh.selector.
      Likewise for eh.typeid.for.  This aligns us with gcc, which always uses a
      32 bit value for the selector on all platforms.  My understanding is that
      the register allocator used to assert if the selector intrinsic size didn't
      match the pointer size, and this was the reason for introducing the two
      variants.  However my testing shows that this is no longer the case (I
      fixed some bugs in selector lowering yesterday, and some more today in the
      fastisel path; these might have caused the original problems).
      
      llvm-svn: 84106
      8e6ccb65
  19. Oct 06, 2009
  20. Aug 31, 2009
    • Jim Grosbach's avatar
      PR4747 · ce713134
      Jim Grosbach authored
      Shared landing pads run into trouble with SJLJ, as the dispatch table is
      mapped to call sites, and merging the pads will throw that off. There needs
      to be a one-to-one mapping of landing pad exception table entries to invoke
      call points.
      
      Detecting the shared pad during lowering of SJLJ info insn't sufficient, as
      the dispatch function may still need separate destinations to properly
      handle phi-nodes.
      
      llvm-svn: 80530
      ce713134
  21. Aug 23, 2009
  22. Aug 20, 2009
  23. Aug 17, 2009
Loading