This is an archive of the discontinued LLVM Phabricator instance.

Check that emitted instructions meet their predicates on all targets except ARM, Mips, and X86.
ClosedPublic

Authored by dsanders on Oct 14 2016, 7:21 AM.

Details

Summary
  • ARM is omitted from this patch because this check appears to expose bugs in this target.
  • Mips is omitted from this patch because this check either detects bugs or deliberate emission of instructions that don't satisfy their predicates. One deliberate use is the SYNC instruction where the version with an operand is correctly defined as requiring MIPS32 while the version without an operand is defined as an alias of 'SYNC 0' and requires MIPS2.
  • X86 is omitted from this patch because it doesn't use the tablegen-erated MCCodeEmitter infrastructure.

Patches for ARM and Mips will follow.

Depends on D25617

Diff Detail

Repository
rL LLVM

Event Timeline

dsanders updated this revision to Diff 74681.Oct 14 2016, 7:21 AM
dsanders retitled this revision from to Check that emitted instructions meet their predicates on all targets except ARM, Mips, and X86..
dsanders updated this object.
dsanders added inline comments.Oct 14 2016, 7:27 AM
lib/Target/AMDGPU/VOP1Instructions.td
539 ↗(On Diff #74681)

@tstellarAMD: Hi Tom, I'm not sure if this line is correct or not. I've included it because a recent change (r284031) left a '?' in this field and that causes problems in tablegen. Is there a correct predicate to use here?

utils/TableGen/CodeEmitterGen.cpp
332 ↗(On Diff #74681)

I've just noticed I've forgotten something. I intended for the body of this generated function to be guarded with '#ifndef NDEBUG' so that it isn't checked on release builds. I'll post an updated patch soon

This is a great idea, thanks for working on this!

My biggest concern is that there's very little information printed out for a developer to take action on. We absolutely need to have at least the instruction that failed verification printed, and ideally the expected and actual feature sets.

James

lib/Target/AArch64/MCTargetDesc/AArch64MCCodeEmitter.cpp
175 ↗(On Diff #74681)

lowerCamelCase

utils/TableGen/AsmMatcherEmitter.cpp
1417 ↗(On Diff #74681)

Whitespace change

utils/TableGen/CodeEmitterGen.cpp
347 ↗(On Diff #74681)

This absolutely needs to print out the offending instruction, and ideally the required features although as they're encoded in a bitset that's probably quite difficult.

lib/Target/AMDGPU/VOP1Instructions.td
539 ↗(On Diff #74681)

I think this needs to be isVI.

Thanks for the quick feedback.

lib/Target/AArch64/MCTargetDesc/AArch64MCCodeEmitter.cpp
175 ↗(On Diff #74681)

I agree it should be a lower case first letter. The reason it isn't is because the generated function is shared with the AsmMatcher and that one isn't a member function. I'll fix this.

lib/Target/AMDGPU/VOP1Instructions.td
539 ↗(On Diff #74681)

Thanks, I'll update the patch.

utils/TableGen/CodeEmitterGen.cpp
347 ↗(On Diff #74681)

I agree, so far I've been re-running the failing command under lldb, printing Inst.getOpcode() and then looking that up in the generated AsmMatcher but that's a bit long winded.

In the worst case I can generate a table but I'll see if I can re-use existing information first.

dsanders updated this revision to Diff 74858.Oct 17 2016, 9:03 AM
dsanders marked 5 inline comments as done.
dsanders edited edge metadata.
  • Correct the AMDGPU predicate
  • Report instruction that showed the problem and the feature predicate(s) that were not satisfied
  • The other minor changes (whitespace and naming convention)
dsanders marked 4 inline comments as done.Oct 17 2016, 9:07 AM

Marked comments as done

ping..

@jmolloy: Do you have any comments on the latest version if the patch? If not, would you be willing to LGTM it (as well as D25614 and D25617) so I can commit? Thanks

jmolloy accepted this revision.Nov 1 2016, 1:31 AM
jmolloy added a reviewer: jmolloy.
This revision is now accepted and ready to land.Nov 1 2016, 1:31 AM
dsanders closed this revision.Nov 19 2016, 5:15 AM
This revision was automatically updated to reflect the committed changes.
foad added a subscriber: foad.Nov 16 2021, 9:20 AM

Sorry for commenting on such an old patch but I am wondering why was verifyInstructionPredicates implemented inside of MCCodeEmitter? In practice this seem to mean that llc -filetype=obj gets this checking but llc -filetype=asm (the default, as used by almost all lit codegen tests) does not. Would it be possible to move verifyInstructionPredicates somewhere a bit more generic so that both paths can get this checking?

Herald added a project: Restricted Project. · View Herald TranscriptNov 16 2021, 9:20 AM

Sorry for commenting on such an old patch but I am wondering why was verifyInstructionPredicates implemented inside of MCCodeEmitter? In practice this seem to mean that llc -filetype=obj gets this checking but llc -filetype=asm (the default, as used by almost all lit codegen tests) does not. Would it be possible to move verifyInstructionPredicates somewhere a bit more generic so that both paths can get this checking?

I wouldn't rely on this recollection much but IIRC I didn't find a place where the final MCInsts were known and the code hadn't already diverged into asm/obj paths. I think the last pass before the paths diverged sometimes emitted different MCInst's down each path too

If we can do it somewhere where it affects both then that'd be great.

foad added a comment.Nov 22 2021, 4:03 AM

Sorry for commenting on such an old patch but I am wondering why was verifyInstructionPredicates implemented inside of MCCodeEmitter? In practice this seem to mean that llc -filetype=obj gets this checking but llc -filetype=asm (the default, as used by almost all lit codegen tests) does not. Would it be possible to move verifyInstructionPredicates somewhere a bit more generic so that both paths can get this checking?

I wouldn't rely on this recollection much but IIRC I didn't find a place where the final MCInsts were known and the code hadn't already diverged into asm/obj paths. I think the last pass before the paths diverged sometimes emitted different MCInst's down each path too

If we can do it somewhere where it affects both then that'd be great.

Here's a demonstration that it *can* work, by making <Target>MCCodeEmitter::verifyInstructionPredicates static and calling into it from <Target>InstPrinter. But that doesn't seem very clean. I'd prefer to find a more neutral place to put verifyInstructionPredicates, but I'm not too familiar with the various classes that TableGen creates,

https://github.com/jayfoad/llvm-project/commits/verify-predicates (top three commits)