Skip to content
  1. Jul 26, 2004
  2. Jul 25, 2004
  3. Jul 18, 2004
    • Reid Spencer's avatar
      bug 122: · ce6adaff
      Reid Spencer authored
      - Replace ConstantPointerRef usage with GlobalValue usage
      - Minimize redundant isa<GlobalValue> usage
      - Correct isa<Constant> for GlobalValue subclass
      - Remove tabs
      - Fix coments refering to ConstantPointerRef
      
      llvm-svn: 14937
      ce6adaff
  4. Jul 16, 2004
  5. Jul 15, 2004
    • Chris Lattner's avatar
      This is logically part of the last patch. Just more really horrible code · 4babbe04
      Chris Lattner authored
      that is made unnecessary by it.
      
      llvm-svn: 14831
      4babbe04
    • Chris Lattner's avatar
      ** Finally DeclareNewGlobalValue is dead! · 8abe1a11
      Chris Lattner authored
      * Simplify a lot of code because type's cannot be in function symbol tables
      * Fix memory leaks in handling of redefined function prototypes
      * Don't use SymbolTable directly for stuff that we can go through the Module
        for.
      * Fix some minor bugs on obscure testcases like:
            test/Feature/globalredefinition.ll
      * Do not create GlobalVariable objects for forward referenced Functions!
      * When forward referencing a function in a constant expression, do not create
        a placeholder, add a bunch of references to it, then turn around and
        replaceAllUsesOfWith on it with a new global, deleting the placeholder.
        Instead, when we find the real definition of the global, just use the
        placeholder instead of creating a new object.
      
      This substantially simplifies the asmwriter and should even speed it up on
      cases heavy in constantexprs (like C++, Java, MSIL)...
      
      llvm-svn: 14830
      8abe1a11
  6. Jul 14, 2004
  7. Jul 13, 2004
  8. Jul 09, 2004
  9. Jul 04, 2004
  10. Jun 17, 2004
  11. May 28, 2004
  12. May 26, 2004
  13. May 25, 2004
  14. Apr 18, 2004
  15. Apr 05, 2004
  16. Mar 31, 2004
  17. Mar 30, 2004
  18. Mar 12, 2004
  19. Mar 08, 2004
  20. Feb 09, 2004
    • Chris Lattner's avatar
      It turns out that the two dimensional vectors were causing big slowdowns · 7289e628
      Chris Lattner authored
      in this for programs with lots of types (like the testcase in PR224).
      The problem was that the type ID that the outer vector was using was not
      very dense (as many types are getting resolved), so the vector is large
      and gets reallocated a lot.
      
      Since there are a lot of values in the program (the .ll file is 10M),
      each reallocation has to copy the subvectors, which is also quite slow
      (this wouldn't be a problem if C++ supported move semantics, but it
      doesn't, at least not yet :(
      
      Changing the outer data structure to a map speeds a release build of
      llvm-as up from 11.21s to 5.13s on the testcase in PR224.
      
      llvm-svn: 11244
      7289e628
    • Chris Lattner's avatar
      When resolving upreferences, if multiple uprefs will be resolved to the same · edd4500c
      Chris Lattner authored
      type at the same time, resolve the upreferences to each other before resolving
      it to the outer type.  This shaves off some time from the testcase in PR224, from
      25.41s -> 21.72s.
      
      llvm-svn: 11241
      edd4500c
Loading