Skip to content
  1. Jun 17, 2015
    • Toma Tabacu's avatar
      [mips] [IAS] Add test for SW with relative label operands. NFC. · 6a1e0eb2
      Toma Tabacu authored 
      Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D10497

llvm-svn: 239899
      6a1e0eb2
    • Toma Tabacu's avatar
      [mips] [IAS] Fix LW with relative label operands. · 07c97b3b
      Toma Tabacu authored 
      Summary:
Previously, MCSymbolRefExpr::create() was called with a StringRef of the symbol
name, which it would then search for in the Symbols StringMap (from MCContext).

However, relative labels (which are temporary symbols) are apparently not stored
in the Symbols StringMap, so we end up creating a new {$,.L}tmp symbol
({$,.L}tmp00, {$,.L}tmp10 etc.) each time we create an MCSymbolRefExpr by
passing in the symbol name as a StringRef.

Fortunately, there is a version of MCSymbolRefExpr::create() which takes an
MCSymbol* and we already have an MCSymbol* at that point, so we can just pass
that in instead of the StringRef.

I also removed the local StringRef calls to MCSymbolRefExpr::create() from
expandMemInst(), as those cases can be handled by evaluateRelocExpr() anyway.

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D9938

llvm-svn: 239897
      07c97b3b
  3. Jun 16, 2015
    • Daniel Sanders's avatar
      [mips][ias] Expand on r238751 to cover as many relocs as possible. · 58405d85
      Daniel Sanders authored 
      Summary:
Relocs that can be converted from absolute to PC-relative now do so if IsPCRel
is true. Relocs that require PC-relative now call llvm_unreachable() if IsPCRel
is false and similarly those that require absolute assert that IsPCRel is false.

Note that while it looks like some relocs (e.g. R_MIPS_26) can be converted into
the MIPS32r6/MIPS64r6 relocs (R_MIPS_PC*_S2), it isn't actually valid to do so.

Placeholders have been left in the testcase for unsupported relocs and relocs
that cannot be generated at the moment.

Reviewers: vkalintiris

Reviewed By: vkalintiris

Subscribers: llvm-commits, rafael

Differential Revision: http://reviews.llvm.org/D10184

llvm-svn: 239817
      58405d85
  5. Jun 11, 2015
  7. Jun 09, 2015
  9. Jun 05, 2015
    • Toma Tabacu's avatar
      Revert "[mips] [IAS] Restore STI.FeatureBits in .set pop." (r239144). · 399a56d7
      Toma Tabacu authored 
      This is breaking the Windows buildbots.

llvm-svn: 239145
      399a56d7
    • Toma Tabacu's avatar
      [mips] [IAS] Restore STI.FeatureBits in .set pop. · 89ebf88f
      Toma Tabacu authored 
      Summary:
Only restoring AvailableFeatures is not enough and will lead to buggy behaviour.
For example, if we have a feature enabled and we ".set pop", the next time we try
to ".set" that feature nothing will happen because the "!(STI.getFeatureBits()[Feature])"
check will be false, because we didn't restore STI.FeatureBits.

In order to fix this, we need to make MipsAssemblerOptions remember the STI.FeatureBits
instead of the AvailableFeatures and then regenerate AvailableFeatures each time we ".set pop".
This is because, AFAIK, there is no way to convert from AvailableFeatures back to STI.FeatureBits,
but the reverse is possible by using ComputeAvailableFeatures(STI.FeatureBits).

I also moved the updating of AssemblerOptions inside the "if" statement in
setFeatureBits() and clearFeatureBits(), as there is no reason to update if
nothing changes.

Reviewers: dsanders, mkuper

Reviewed By: dsanders

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D9156

llvm-svn: 239144
      89ebf88f
  11. Jun 04, 2015
  13. Jun 02, 2015
  15. Jun 01, 2015
  17. May 28, 2015
  19. May 27, 2015
  21. May 22, 2015
  23. May 21, 2015
  25. May 19, 2015
  27. May 18, 2015
  29. May 15, 2015
    • Toma Tabacu's avatar
      [mips] [IAS] Fix expansion of negative 32-bit immediates for LI/DLI. · a3d056fd
      Toma Tabacu authored 
      Summary:
To maintain compatibility with GAS, we need to stop treating negative 32-bit immediates as 64-bit values when expanding LI/DLI.
This currently happens because of sign extension.

To do this we need to choose the 32-bit value expansion for values which use their upper 33 bits only for sign extension (i.e. no 0's, only 1's).

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D8662

llvm-svn: 237428
      a3d056fd
  31. May 14, 2015
  33. May 13, 2015
  35. May 12, 2015
  37. May 08, 2015
  39. May 07, 2015
  41. May 05, 2015