Skip to content
  1. Sep 15, 2010
  2. Sep 10, 2010
  3. Aug 28, 2010
  4. Aug 11, 2010
  5. Aug 06, 2010
  6. Jul 28, 2010
  7. Jul 22, 2010
  8. Apr 23, 2010
  9. Apr 17, 2010
  10. Apr 08, 2010
  11. Apr 02, 2010
  12. Mar 16, 2010
  13. Feb 25, 2010
  14. Feb 24, 2010
    • Dan Gohman's avatar
      Make getTypeSizeInBits work correctly for array types; it should return · 4b2b48da
      Dan Gohman authored
      the number of value bits, not the number of bits of allocation for in-memory
      storage.
      
      Make getTypeStoreSize and getTypeAllocSize work consistently for arrays and
      vectors.
      
      Fix several places in CodeGen which compute offsets into in-memory vectors
      to use TargetData information.
      
      This fixes PR1784.
      
      llvm-svn: 97064
      4b2b48da
  15. Feb 16, 2010
  16. Jan 26, 2010
  17. Dec 17, 2009
  18. Dec 05, 2009
  19. Dec 04, 2009
  20. Dec 03, 2009
  21. Nov 18, 2009
    • Bill Wendling's avatar
      The llvm-gcc front-end and the pass manager use two separate TargetData objects. · dfd8daaf
      Bill Wendling authored
      This is probably not confined to *just* these two things.
      
      Anyway, the llvm-gcc front-end may look up the structure layout information for
      an abstract type. That information will be stored into a table with the FE's
      TD. Instruction combine can come along and also ask for information on that
      abstract type, but for a separate TD (the one associated with the pass manager).
      
      After the type is refined, the old structure layout information in the pass
      manager's TD file is out of date. If a new type is allocated in the same space
      as the old-unrefined type, then the structure type information in the pass
      manager's TD file will be wrong, but won't know it.
      
      Fix this by making the TD's structure type information an abstract type user.
      
      llvm-svn: 89176
      dfd8daaf
  22. Nov 08, 2009
  23. Nov 07, 2009
  24. Aug 21, 2009
Loading