Skip to content
  1. Nov 15, 2013
    • Andrew Trick's avatar
      When folding memory operands, preserve existing MachineMemOperands. · a9f4d928
      Andrew Trick authored
      This comes into play with patchpoint, which can fold multiple
      operands. Since the patchpoint is already treated as a call, the
      machine mem operands won't affect anything, and there's nothing to
      test. But we still want to do the right thing here to be sure that our
      MIs obey the rules.
      
      llvm-svn: 194750
      a9f4d928
  2. Nov 14, 2013
  3. Nov 13, 2013
  4. Nov 11, 2013
  5. Nov 10, 2013
    • Arnaud A. de Grandmaison's avatar
      CalculateSpillWeights does not need to be a pass · 760c1e0b
      Arnaud A. de Grandmaison authored
      Based on discussions with Lang Hames and Jakob Stoklund Olesen at the hacker's lab, and in the light of upcoming work on the PBQP register allocator, it was though that CalcSpillWeights does not need to be a pass. This change will enable to customize / tune the spill weight computation depending on the allocator.
      
      Update the documentation style while there.
      
      No functionnal change.
      
      llvm-svn: 194356
      760c1e0b
    • Matt Arsenault's avatar
      Use type form of getIntPtrType. · c900303e
      Matt Arsenault authored
      This should be inconsequential and is work
      towards removing the default address space
      arguments.
      
      llvm-svn: 194347
      c900303e
  6. Nov 09, 2013
    • Lang Hames's avatar
      Re-apply r194300 with fixes for warnings. · fb82630a
      Lang Hames authored
      llvm-svn: 194311
      fb82630a
    • Nick Lewycky's avatar
      Revert r194300 which broke the build. · 59886d00
      Nick Lewycky authored
      llvm-svn: 194308
      59886d00
    • Juergen Ributzka's avatar
      [Stackmap] Materialize the jump address within the patchpoint noop slide. · 87ed906b
      Juergen Ributzka authored
      This patch moves the jump address materialization inside the noop slide. This
      enables patching of the materialization itself or its complete removal. This
      patch also adds the ability to define scratch registers that can be used safely
      by the code called from the patchpoint intrinsic. At least one scratch register
      is required, because that one is used for the materialization of the jump
      address. This patch depends on D2009.
      
      Differential Revision: http://llvm-reviews.chandlerc.com/D2074
      
      Reviewed by Andy
      
      llvm-svn: 194306
      87ed906b
    • Lang Hames's avatar
      Rewrite the PBQP graph data structure. · 1662b832
      Lang Hames authored
      The new graph structure replaces the node and edge linked lists with vectors.
      Free lists (well, free vectors) are used for fast insertion/deletion.
      
      The ultimate aim is to make PBQP graphs cheap to clone. The motivation is that
      the PBQP solver destructively consumes input graphs while computing a solution,
      forcing the graph to be fully reconstructed for each round of PBQP. This
      imposes a high cost on large functions, which often require several rounds of
      solving/spilling to find a final register allocation. If we can cheaply clone
      the PBQP graph and incrementally update it between rounds then hopefully we can
      reduce this cost. Further, once we begin pooling matrix/vector values (future
      work), we can cache some PBQP solver metadata and share it between cloned
      graphs, allowing the PBQP solver to re-use some of the computation done in
      earlier rounds.
      
      For now this is just a data structure update. The allocator and solver still
      use the graph the same way as before, fully reconstructing it between each
      round. I expect no material change from this update, although it may change
      the iteration order of the nodes, causing ties in the solver to break in
      different directions, and this could perturb the generated allocations
      (hopefully in a completely benign way).
      
      Thanks very much to Arnaud Allard de Grandmaison for encouraging me to get back
      to work on this, and for a lot of discussion and many useful PBQP test cases.
      
      llvm-svn: 194300
      1662b832
    • Juergen Ributzka's avatar
      [Stackmap] Add AnyReg calling convention support for patchpoint intrinsic. · 9969d3e6
      Juergen Ributzka authored
      The idea of the AnyReg Calling Convention is to provide the call arguments in
      registers, but not to force them to be placed in a paticular order into a
      specified set of registers. Instead it is up tp the register allocator to assign
      any register as it sees fit. The same applies to the return value (if
      applicable).
      
      Differential Revision: http://llvm-reviews.chandlerc.com/D2009
      
      Reviewed by Andy
      
      llvm-svn: 194293
      9969d3e6
  7. Nov 08, 2013
  8. Nov 05, 2013
    • Andrew Trick's avatar
      Slightly change the way stackmap and patchpoint intrinsics are lowered. · 6664df12
      Andrew Trick authored
      MorphNodeTo is not safe to call during DAG building. It eagerly
      deletes dependent DAG nodes which invalidates the NodeMap. We could
      expose a safe interface for morphing nodes, but I don't think it's
      worth it. Just create a new MachineNode and replaceAllUsesWith.
      
      My understaning of the SD design has been that we want to support
      early target opcode selection. That isn't very well supported, but
      generally works. It seems reasonable to rely on this feature even if
      it isn't widely used.
      
      llvm-svn: 194102
      6664df12
  9. Nov 02, 2013
  10. Nov 01, 2013
  11. Oct 31, 2013
    • Andrew Trick's avatar
      Unused variable · c21d86f7
      Andrew Trick authored
      llvm-svn: 193819
      c21d86f7
    • Andrew Trick's avatar
      Add support for stack map generation in the X86 backend. · 153ebe6d
      Andrew Trick authored
      Originally implemented by Lang Hames.
      
      llvm-svn: 193811
      153ebe6d
    • Manman Ren's avatar
      Debug Info: remove duplication of DIEs when a DIE can be shared across CUs. · 4dbdc902
      Manman Ren authored
      We add a map in DwarfDebug to map MDNodes that are shareable across CUs to the
      corresponding DIEs: MDTypeNodeToDieMap. These DIEs can be shared across CUs,
      that is why we keep the maps in DwarfDebug instead of CompileUnit.
      
      We make the assumption that if a DIE is not added to an owner yet, we assume
      it belongs to the current CU. Since DIEs for the type system are added to
      their owners immediately after creation, and other DIEs belong to the current
      CU, the assumption should be true.
      
      A testing case is added to show that we only create a single DIE for a type
      MDNode and we use ref_addr to refer to the type DIE.
      
      We also add a testing case to show ref_addr relocations for non-darwin
      platforms.
      
      llvm-svn: 193779
      4dbdc902
Loading