Skip to content
  1. Aug 22, 2013
  2. Aug 16, 2013
  3. Aug 14, 2013
  4. Aug 12, 2013
    • Richard Sandiford's avatar
      Revert r188164: Stablize MCK_Reg ordering in AsmMatcherEmitter · 173cf407
      Richard Sandiford authored
      Apparently caused a failure on Darwin
      
      llvm-svn: 188166
      173cf407
    • Richard Sandiford's avatar
      Stablize MCK_Reg ordering in AsmMatcherEmitter · 3e2cbf18
      Richard Sandiford authored
      clang bootstraps intermittently failed for me due a difference in
      the MCK_Reg ordering in ARMGenAsmMatcher.inc.  E.g. in my latest
      run the stage 1 and stage 3 versions were the same but the stage 2
      one was different (though still functionally correct).  This meant
      that the .o comparison failed.
      
      MCK_Regs were assigned by iterating over a std::set< std::set<Record*> >,
      and since std::set is sorted lexicographically, the order depended on the
      order of the pointer values.  This patch replaces the pointer ordering
      with LessRecordByID.
      
      llvm-svn: 188164
      3e2cbf18
  5. Aug 07, 2013
  6. Aug 01, 2013
  7. Jul 31, 2013
  8. Jul 28, 2013
  9. Jul 26, 2013
  10. Jul 25, 2013
    • Justin Holewinski's avatar
      Fix a bug in TableGen where the intrinsic function name recognizer could... · b3d630ca
      Justin Holewinski authored
      Fix a bug in TableGen where the intrinsic function name recognizer could mis-identify names if one was a prefix substring of the other
      
      For two intrinsics 'llvm.nvvm.texsurf.handle' and 'llvm.nvvm.texsurf.handle.internal',
      TableGen was emitting matching code like:
      
        if (Name.startswith("llvm.nvvm.texsurf.handle")) ...
        if (Name.startswith("llvm.nvvm.texsurf.handle.internal")) ...
      
      We can never match "llvm.nvvm.texsurf.handle.internal" here because it will
      always be erroneously matched by the first condition.
      
      The fix is to sort the intrinsic names and emit them in reverse order.
      
      llvm-svn: 187119
      b3d630ca
    • Andrew Trick's avatar
      RegPressure: Order the "pressure sets" by number of regunits per set. · 3aacca46
      Andrew Trick authored
      This lets heuristics easily pick the most important set to follow.
      
      llvm-svn: 187108
      3aacca46
  11. Jul 24, 2013
  12. Jul 23, 2013
  13. Jul 16, 2013
  14. Jul 15, 2013
  15. Jul 14, 2013
  16. Jul 06, 2013
  17. Jul 04, 2013
  18. Jun 27, 2013
    • Chad Rosier's avatar
      Improve the compression of the tablegen DiffLists by introducing a new sort · ccd06643
      Chad Rosier authored
      algorithm when assigning EnumValues to the synthesized registers.
      
      The current algorithm, LessRecord, uses the StringRef compare_numeric
      function.  This function compares strings, while handling embedded numbers.
      For example, the R600 backend registers are sorted as follows:
      
        T1
        T1_W
        T1_X
        T1_XYZW
        T1_Y
        T1_Z
        T2
        T2_W
        T2_X
        T2_XYZW
        T2_Y
        T2_Z
      
      In this example, the 'scaling factor' is dEnum/dN = 6 because T0, T1, T2
      have an EnumValue offset of 6 from one another.  However, in other parts
      of the register bank, the scaling factors are different:
      
      dEnum/dN = 5:
        KC0_128_W
        KC0_128_X
        KC0_128_XYZW
        KC0_128_Y
        KC0_128_Z
        KC0_129_W
        KC0_129_X
        KC0_129_XYZW
        KC0_129_Y
        KC0_129_Z
      
      The diff lists do not work correctly because different kinds of registers have
      different 'scaling factors'.  This new algorithm, LessRecordRegister, tries to
      enforce a scaling factor of 1.  For example, the registers are now sorted as
      follows:
      
        T1
        T2
        T3
        ...
        T0_W
        T1_W
        T2_W
        ...
        T0_X
        T1_X
        T2_X
        ...
        KC0_128_W
        KC0_129_W
        KC0_130_W
        ...
      
      For the Mips and R600 I see a 19% and 6% reduction in size, respectively.  I
      did see a few small regressions, but the differences were on the order of a
      few bytes (e.g., AArch64 was 16 bytes).  I suspect there will be even
      greater wins for targets with larger register files.
      
      Patch reviewed by Jakob.
      rdar://14006013
      
      llvm-svn: 185094
      ccd06643
  19. Jun 25, 2013
    • Tom Stellard's avatar
      TableGen: Generate a function for getting operand indices based on their defined names · b162d948
      Tom Stellard authored
      This patch modifies TableGen to generate a function in
      ${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
      to look up indices for operands based on their names.
      
      In order to activate this feature for an instruction, you must set the
      UseNamedOperandTable bit.
      
      For example, if you have an instruction like:
      
      def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
      
      You can look up the operand indices using the new function, like this:
      
      Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst)  => 0
      Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
      Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
      
      The operand names are case sensitive, so $dst and $DST are considered
      different operands.
      
      This change is useful for R600 which has instructions with a large number
      of operands, many of which model single bit instruction configuration
      values.  These configuration bits are common across most instructions,
      but may have a different operand index depending on the instruction type.
      It is useful to have a convenient way to look up the operand indices,
      so these bits can be generically set on any instruction.
      
      llvm-svn: 184879
      b162d948
  20. Jun 18, 2013
  21. Jun 15, 2013
  22. Jun 10, 2013
  23. Jun 09, 2013
  24. Jun 07, 2013
  25. Jun 06, 2013
Loading