Skip to content
  1. Jun 18, 2009
  2. Jun 16, 2009
  3. Jun 15, 2009
  4. Jun 13, 2009
    • Devang Patel's avatar
      llvm.dbg.region.end() intrinsic is not required to be in _last_ basic block in... · 64e6529e
      Devang Patel authored
      llvm.dbg.region.end() intrinsic is not required to be in _last_ basic block in a function.  If that happens then any basic block that follows (lexically) the block with regin.end will not have scope info available.  LexicalScopeStack relies on processing basic block in CFG order, but this processing order is not guaranteed. Things get complicated when the optimizer gets a chance to optimizer IR with dbg intrinsics. 
      Apply defensive patch to preserve at least one lexical scope till the end of function.
      
      llvm-svn: 73282
      64e6529e
  5. Jun 12, 2009
  6. Jun 05, 2009
  7. Jun 01, 2009
  8. May 30, 2009
  9. May 21, 2009
  10. May 19, 2009
  11. May 15, 2009
  12. May 14, 2009
  13. May 13, 2009
  14. May 12, 2009
  15. May 11, 2009
    • Bill Wendling's avatar
      This is a large rewrite of how Dwarf info for inlined functions is handled. · 59b1ca2a
      Bill Wendling authored
      The DwarfWriter expects DbgScopes and DIEs to behave themselves according to
      DwarfWriter's rules. However, inlined functions violate these rules. There are
      two different types of DIEs associated with an inlined function: an abstract
      instance, which has information about the original source code for the function
      being inlined; and concrete instances, which are created for each place the
      function was inlined and point back to the abstract instance.
      
      This patch tries to stay true to this schema. It bypasses how regular DbgScopes
      and DIEs are created and used when necessary. It provides special handling for
      DIEs of abstract and concrete instances.
      
      This doesn't take care of all of the problems with debug info for inlined
      functions, but it's a step in the right direction. For one thing, llvm-gcc
      generates wrong IR (it's missing some llvm.dbg intrinsics at the point where the
      function's inlined) for this example:
      
      #include <stdio.h>
      static __inline__ __attribute__((always_inline))  int bar(int x) { return 4; }
      void foo() {
        long long b = 1;
        int Y = bar(4);
        printf("%d\n", Y);
      }
      
      while clang generates correct IR.
      
      llvm-svn: 71410
      59b1ca2a
  16. May 09, 2009
  17. May 08, 2009
  18. May 07, 2009
Loading