Skip to content
  1. Jun 15, 2013
  2. Jun 07, 2013
  3. May 29, 2013
  4. May 13, 2013
    • Rafael Espindola's avatar
      Remove the MachineMove class. · 227144c2
      Rafael Espindola authored
      It was just a less powerful and more confusing version of
      MCCFIInstruction. A side effect is that, since MCCFIInstruction uses
      dwarf register numbers, calls to getDwarfRegNum are pushed out, which
      should allow further simplifications.
      
      I left the MachineModuleInfo::addFrameMove interface unchanged since
      this patch was already fairly big.
      
      llvm-svn: 181680
      227144c2
  5. May 11, 2013
  6. May 02, 2013
  7. May 01, 2013
  8. Apr 30, 2013
  9. Apr 27, 2013
    • Eric Christopher's avatar
      Use the target triple from the target machine rather than the module · 203e12bf
      Eric Christopher authored
      to determine whether or not we're on a darwin platform for debug code
      emitting.
      
      Solves the problem of a module with no triple on the command line
      and no triple in the module using non-gdb ok features on darwin. Fix
      up the member-pointers test to check the correct things for cross
      platform (DW_FORM_flag is a good prefix).
      
      Unfortunately no testcase because I have no ideas how to test something
      without a triple and without a triple in the module yet check
      precisely on two platforms. Ideas welcome.
      
      llvm-svn: 180660
      203e12bf
  10. Apr 26, 2013
    • Adrian Prantl's avatar
      Cleanup and document MachineLocation. · d4c0dd47
      Adrian Prantl authored
      Clarify documentation and API to make the difference between register and
      register-indirect addressed locations more explicit. Put in a comment
      to point out that with the current implementation we cannot specify
      a register-indirect location with offset 0 (a breg 0 in DWARF).
      No functionality change intended.
      
      rdar://problem/13658587
      
      llvm-svn: 180641
      d4c0dd47
  11. Apr 22, 2013
  12. Apr 17, 2013
  13. Jan 11, 2013
  14. Jan 09, 2013
  15. Jan 08, 2013
  16. Jan 02, 2013
    • Chandler Carruth's avatar
      Move all of the header files which are involved in modelling the LLVM IR · 9fb823bb
      Chandler Carruth authored
      into their new header subdirectory: include/llvm/IR. This matches the
      directory structure of lib, and begins to correct a long standing point
      of file layout clutter in LLVM.
      
      There are still more header files to move here, but I wanted to handle
      them in separate commits to make tracking what files make sense at each
      layer easier.
      
      The only really questionable files here are the target intrinsic
      tablegen files. But that's a battle I'd rather not fight today.
      
      I've updated both CMake and Makefile build systems (I think, and my
      tests think, but I may have missed something).
      
      I've also re-sorted the includes throughout the project. I'll be
      committing updates to Clang, DragonEgg, and Polly momentarily.
      
      llvm-svn: 171366
      9fb823bb
  17. Dec 30, 2012
  18. Dec 12, 2012
    • Pedro Artigas's avatar
      · 7212ee45
      Pedro Artigas authored
      Make the MCStreamer have a reset method and call that after finalization of the asm printer, 
      also changed MCContext to a single reset only method for simplicity as requested on the list
      
      llvm-svn: 170041
      7212ee45
  19. Dec 10, 2012
  20. Dec 03, 2012
    • Chandler Carruth's avatar
      Use the new script to sort the includes of every file under lib. · ed0881b2
      Chandler Carruth authored
      Sooooo many of these had incorrect or strange main module includes.
      I have manually inspected all of these, and fixed the main module
      include to be the nearest plausible thing I could find. If you own or
      care about any of these source files, I encourage you to take some time
      and check that these edits were sensible. I can't have broken anything
      (I strictly added headers, and reordered them, never removed), but they
      may not be the headers you'd really like to identify as containing the
      API being implemented.
      
      Many forward declarations and missing includes were added to a header
      files to allow them to parse cleanly when included first. The main
      module rule does in fact have its merits. =]
      
      llvm-svn: 169131
      ed0881b2
  21. Nov 27, 2012
    • Ulrich Weigand's avatar
      Never use .lcomm on platforms where it does not accept an alignment · e5f94058
      Ulrich Weigand authored
      argument.  Instead, use a pair of .local and .comm directives.
      
      This avoids spurious differences between binaries built by the
      integrated assembler vs. those built by the external assembler,
      since the external assembler may impose alignment requirements
      on .lcomm symbols where the integrated assembler does not.
      
      llvm-svn: 168704
      e5f94058
  22. Nov 20, 2012
  23. Nov 01, 2012
    • Chandler Carruth's avatar
      Revert the majority of the next patch in the address space series: · 5da3f051
      Chandler Carruth authored
      r165941: Resubmit the changes to llvm core to update the functions to
               support different pointer sizes on a per address space basis.
      
      Despite this commit log, this change primarily changed stuff outside of
      VMCore, and those changes do not carry any tests for correctness (or
      even plausibility), and we have consistently found questionable or flat
      out incorrect cases in these changes. Most of them are probably correct,
      but we need to devise a system that makes it more clear when we have
      handled the address space concerns correctly, and ideally each pass that
      gets updated would receive an accompanying test case that exercises that
      pass specificaly w.r.t. alternate address spaces.
      
      However, from this commit, I have retained the new C API entry points.
      Those were an orthogonal change that probably should have been split
      apart, but they seem entirely good.
      
      In several places the changes were very obvious cleanups with no actual
      multiple address space code added; these I have not reverted when
      I spotted them.
      
      In a few other places there were merge conflicts due to a cleaner
      solution being implemented later, often not using address spaces at all.
      In those cases, I've preserved the new code which isn't address space
      dependent.
      
      This is part of my ongoing effort to clean out the partial address space
      code which carries high risk and low test coverage, and not likely to be
      finished before the 3.2 release looms closer. Duncan and I would both
      like to see the above issues addressed before we return to these
      changes.
      
      llvm-svn: 167222
      5da3f051
    • Chandler Carruth's avatar
      Revert the series of commits starting with r166578 which introduced the · 7ec5085e
      Chandler Carruth authored
      getIntPtrType support for multiple address spaces via a pointer type,
      and also introduced a crasher bug in the constant folder reported in
      PR14233.
      
      These commits also contained several problems that should really be
      addressed before they are re-committed. I have avoided reverting various
      cleanups to the DataLayout APIs that are reasonable to have moving
      forward in order to reduce the amount of churn, and minimize the number
      of commits that were reverted. I've also manually updated merge
      conflicts and manually arranged for the getIntPtrType function to stay
      in DataLayout and to be defined in a plausible way after this revert.
      
      Thanks to Duncan for working through this exact strategy with me, and
      Nick Lewycky for tracking down the really annoying crasher this
      triggered. (Test case to follow in its own commit.)
      
      After discussing with Duncan extensively, and based on a note from
      Micah, I'm going to continue to back out some more of the more
      problematic patches in this series in order to ensure we go into the
      LLVM 3.2 branch with a reasonable story here. I'll send a note to
      llvmdev explaining what's going on and why.
      
      Summary of reverted revisions:
      
      r166634: Fix a compiler warning with an unused variable.
      r166607: Add some cleanup to the DataLayout changes requested by
               Chandler.
      r166596: Revert "Back out r166591, not sure why this made it through
               since I cancelled the command. Bleh, sorry about this!
      r166591: Delete a directory that wasn't supposed to be checked in yet.
      r166578: Add in support for getIntPtrType to get the pointer type based
               on the address space.
      llvm-svn: 167221
      7ec5085e
  24. Oct 24, 2012
  25. Oct 15, 2012
  26. Oct 11, 2012
  27. Oct 08, 2012
  28. Sep 25, 2012
  29. Sep 07, 2012
    • Benjamin Kramer's avatar
      Fix alignment of .comm and .lcomm on mingw32. · 68b9f058
      Benjamin Kramer authored
      For some reason .lcomm uses byte alignment and .comm log2 alignment so we can't
      use the same setting for both. Fix this by reintroducing the LCOMM enum.
      I verified this against mingw's gcc.
      
      llvm-svn: 163420
      68b9f058
    • Chad Rosier's avatar
      b759ede9
    • Benjamin Kramer's avatar
      MC: Overhaul handling of .lcomm · 47f9ec92
      Benjamin Kramer authored
      - Darwin lied about not supporting .lcomm and turned it into zerofill in the
        asm parser. Push the zerofill-conversion down into macho-specific code.
      - This makes the tri-state LCOMMType enum superfluous, there are no targets
        without .lcomm.
      - Do proper error reporting when trying to use .lcomm with alignment on a target
        that doesn't support it.
      - .comm and .lcomm alignment was parsed in bytes on COFF, should be power of 2.
      - Fixes PR13755 (.lcomm crashes on ELF).
      
      llvm-svn: 163395
      47f9ec92
  30. Aug 25, 2012
  31. Aug 17, 2012
    • Bill Wendling's avatar
      Change the `linker_private_weak_def_auto' linkage to `linkonce_odr_auto_hide' to · 34bc34ec
      Bill Wendling authored
      make it more consistent with its intended semantics.
      
      The `linker_private_weak_def_auto' linkage type was meant to automatically hide
      globals which never had their addresses taken. It has nothing to do with the
      `linker_private' linkage type, which outputs the symbols with a `l' (ell) prefix
      among other things.
      
      The intended semantic is more like the `linkonce_odr' linkage type.
      
      Change the name of the linkage type to `linkonce_odr_auto_hide'. And therefore
      changing the semantics so that it produces the correct output for the linker.
      
      Note: The old linkage name `linker_private_weak_def_auto' will still parse but
      is not a synonym for `linkonce_odr_auto_hide'. This should be removed in 4.0.
      <rdar://problem/11754934>
      
      llvm-svn: 162114
      34bc34ec
  32. Jun 28, 2012
Loading