The patch implements microMIPSDSP instructions: PACKRL.PH, PICK.PH, PICK.QB, SHILO, SHILOV and WRDSP.
Details
Diff Detail
Event Timeline
This is almost there but it introduces some dangerous 'let Predicates = ' statements. I'd like you to make an easy change to the existing DSP ASE to avoid it (and bring it into line with our recent work) as described below.
lib/Target/Mips/MipsDSPInstrInfo.td | ||
---|---|---|
1215 | I have to insist that we don't introduce more 'let Predicates = ' statements, they're dangerous since they can easily lose predicates. *Just add PredicateControl as a base class of DSPInst, set InsnPredicates appropriately in DSPInst, and adapt the existing 'let Predicates =' statements to adjectives or let statements on the sub-lists appropriately. | |
1450 | Likewise |
Existing DSP ASE changed so it use PredicateControl instead of 'let Predicates =' statements.
PredicateControl added to DSPInst and PseudoDSP as a base class.
'let Predicates =' replaced with 'let InsnPredicates ='.
Used AdditionalPredicates for NotInMicroMips.
Rebased to work with top of the tree.
Old uimm10 operand definition replaced with new one which uses ConstantUImmAsmOperandClass.
Added uimm7_report_uimm and uimm10_report_uimm operands for implementation of WRDSP (MIPS version of WRDSP has 10-bit unsigned immediate while microMIPS version has 7-bit unsigned immediate).
Changed definition of simm6 operand to use new MipsSImmAsmOperandClass with DiagnosticType and SuperClasses members.
Implemented new match types in MipsAsmParser.cpp.
microMIPSDSPr1 assembler and disassembler tests added to microMIPSDSPr2 test files.
Updated expected error messages in invalid test files.
lib/Target/Mips/AsmParser/MipsAsmParser.cpp | ||
---|---|---|
3279–3281 | Is there a reason to not give the range? I suspect this ought to be a plain Match_UImm7_0 similar to the others and the operand in the *_DESC should be updated accordingly. I'm thinking it might be because it hits the same wrong-error issue that I encounter in my WIP patch for range-checked uimm16. For now I'm using the correct range-checked immediates and putting the problem cases in invalid-wrong-error.s files. I'm thinking that we should extend the error reporting to report multiple reasons for a failed match. For example: filename.s:10:19: error: expected 7-bit unsigned immediate, or 10-bit unsigned immediate if '.set nomicromips' were used. wrdsp $2, -1 ^~ This avoids the need to pick a single representative error message and is more helpful to the user. | |
3290 | Could you add 'signed' to the message so the user doesn't expect 0 - 63. | |
lib/Target/Mips/MipsDSPInstrInfo.td | ||
20 | Is it possible for SHILO's immediate to be a relocatable expression? If not, we should is isConstantSImm | |
lib/Target/Mips/MipsInstrInfo.td | ||
395–398 | You need to add ConstantUImm10AsmOperandClass to the list in the ConstantUImm4AsmOperandClass. This ensures instructions are matched in the correct order (uimm4 first). Otherwise, given the choice between uimm4 and uimm10 it might always pick uimm10 because that appears first in the matching table. Similarly, MipsSImm6AsmOperandClass should be in this list too (and should be defined near here). I was planning to add the signed immediate just above the unsigned ones. I think MipsSImm6AsmOperandClass might need ConstantUImm10AsmOperandClass in its list too but I haven't tested this yet. | |
test/MC/Mips/micromips-dsp/invalid.s | ||
24 | Missing column number. It will point at the mnemonic. |
Replaced Match_UImm7_0_Report_UImm with plain Match_UImm7_0.
Removed Match_UImm10_0_Report_UImm and used Match_UImm10_0 instead.
Error messages are updated accordingly.
SuperClass members of ConstantUImm7AsmOperandClass, ConstantSImm6AsmOperandClass and ConstantUImm5AsmOperandClass are updated so instructions can be matched in the correct order.
ConstantSImmAsmOperandClass and simm6 operand definition are moved to MipsInstrFormats.td (near the definition of ConstantUImmAsmOperandClass).
Added invalid-wrong-error.s for microMIPS DSP.
Problematic test cases for WRDSP instruction moved from invalid.s to invalid-wrong-error.s (they are correctly rejected but currently wrong error message is shown).
LGTM with one change I missed last time.
lib/Target/Mips/MipsInstrInfo.td | ||
---|---|---|
388 | Do you really need a ParserMethod? Integers should parse properly with the default parser. |
lib/Target/Mips/MipsInstrInfo.td | ||
---|---|---|
388 | I agree, ParserMethod is not needed here. I'll remove it from patch. |
Is there a reason to not give the range? I suspect this ought to be a plain Match_UImm7_0 similar to the others and the operand in the *_DESC should be updated accordingly.
I'm thinking it might be because it hits the same wrong-error issue that I encounter in my WIP patch for range-checked uimm16. For now I'm using the correct range-checked immediates and putting the problem cases in invalid-wrong-error.s files. I'm thinking that we should extend the error reporting to report multiple reasons for a failed match. For example:
This avoids the need to pick a single representative error message and is more helpful to the user.