This is an archive of the discontinued LLVM Phabricator instance.

[mips] Add new format for dmtc2/dmfc2 for Octeon CPUs.
ClosedPublic

Authored by Kai on May 27 2015, 10:48 PM.

Details

Summary

Hi Daniel,

Octeon CPUs use dmtc2 rt,imm16 and dmfcp2 rt,imm16 for the crypto coprocessor. E.g. dmtc2 rt,0x4057 starts calculation of sha-1.

I had to introduce a new deconding namespace to avoid a decoding conflict.

Regards,
Kai

Diff Detail

Repository
rL LLVM

Event Timeline

Kai updated this revision to Diff 26661.May 27 2015, 10:48 PM
Kai retitled this revision from to [mips] Add new format for dmtc2/dmfc2 for Octeon CPUs..
Kai updated this object.
Kai edited the test plan for this revision. (Show Details)
Kai added a reviewer: dsanders.
Kai added a subscriber: Unknown Object (MLST).
Kai updated this revision to Diff 26662.May 27 2015, 11:01 PM

Forgot to commit the latest test case changes.

dsanders accepted this revision.May 28 2015, 2:15 AM
dsanders edited edge metadata.

LGTM with a nit.

Just to check: Is the decoder conflict something that happens now (I couldn't reproduce it) or are you accounting for MIPS64 dmfc2/dmtc2's conflicting when they are added?

lib/Target/Mips/Disassembler/MipsDisassembler.cpp
897 ↗(On Diff #26662)

Nit: Indentation, should line up with the 'D' in DecoderTableCnMips32.

This revision is now accepted and ready to land.May 28 2015, 2:15 AM
Kai added a comment.May 28 2015, 2:36 AM

The decoder conflict happens now. I had to explicitly add the DecoderNamespace to get rid of it.

Hmm. I can easily see where the decoder conflict should be but for some reason tablegen isn't reporting it in my build when I delete the explicit DecoderNamespace (and comment out the references to the undefined table this causes).

In any case, your patch is correct. Feel free to commit.

I think I see what's happening in my build. It seems tablegen only complains about decoder conflicts when the mask of literal bits and the values of those masked bits are exactly the same. In the case of DMFC2 vs DMFC2_OCTEON we have:

DMFC2        01001000001_____ _____00000000___
DMFC2_OCTEON 01001000001_____ ________________

So instead of reporting decoder conflicts as an error it quietly prefers DMFC2 when bits 10 down to 3 are 0, and therefore disassembles incorrectly for the CnMips case.

This revision was automatically updated to reflect the committed changes.