This is an archive of the discontinued LLVM Phabricator instance.

[ARM] Include operand class name in dev diags
ClosedPublic

Authored by olista01 on Oct 23 2017, 9:59 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

olista01 created this revision.Oct 23 2017, 9:59 AM
rengolin edited edge metadata.Oct 23 2017, 2:11 PM

This feels like a simple patch that we should keep downstream.

lib/Target/ARM/AsmParser/ARMAsmParser.cpp
10216 ↗(On Diff #119886)

that's a bit hackish, why not always?

Why do you think this should be kept downstream? It's a debug option which I've found useful while adding diagnostics for assembly options, none of which I plan on keeping downstream.

lib/Target/ARM/AsmParser/ARMAsmParser.cpp
10216 ↗(On Diff #119886)

The getMatchClassName is only generated for builds with assertions. This code is only used when the -arm-arm-parser-dev-diags option is used, which is intended for LLVM developers only, so I think it makes sense to keep it this way.

Why do you think this should be kept downstream? It's a debug option which I've found useful while adding diagnostics for assembly options, none of which I plan on keeping downstream.

Because it's an unusual pattern for assembly parsers in general and it may confuse the end user if they happen to build in assert/debug mode.

End user facing messages should be always the same. If you want a debug message, use DEBUG().

Normal users will only ever see the "invalid operand for instruction" part of the diagnostic, regardess of whether they have assertions enabled or not. The extra info is only enabled when the -arm-arm-parser-dev-diags option is used (the "if (DevDiags)" check above), which isn't even exposed as a clang option (you'd need to pass it through with -mllvm).

I made these development diagnostics part of the actual ones because otherwise it is hard to correlate the DEBUG/dbgs output with the emitted diagnostics, which they elaborate on.

Normal users will only ever see the "invalid operand for instruction" part of the diagnostic, regardess of whether they have assertions enabled or not. The extra info is only enabled when the -arm-arm-parser-dev-diags option is used (the "if (DevDiags)" check above), which isn't even exposed as a clang option (you'd need to pass it through with -mllvm).

Isn't this going to be enabled by default some time in the near future?

Isn't this going to be enabled by default some time in the near future?

No, the -arm-arm-parser-dev-diags option is intended to permanently be a devlopment option, akin to -debug(-only) and the llvm-mc options like -show-inst, -show-encoding etc. It expands the diagnostics to include things like opcodes and enum values, to make it easier to work out why a more detailed diagnostic wasn't printed.

Right, looking back, this is the only other use of DevDiags. At all.

I completely missed that when reviewing D31530, and I see now that this is the wrong implementation. We should not have the flag at all, and that should be just a simple usage of DEBUG().

We already have the stderr/stdout sync issue everywhere, and that's not a strong enough reason to add a flag for a single printf (or we wouldn't have DEBUG in the first place).

cheers,
--renato

olista01 updated this revision to Diff 120018.Oct 24 2017, 2:15 AM
  • Remove the -arm-asm-parser-dev-diags option
  • Print the extra info straight to dbgs(), rather than appending to the diagnostic
rengolin accepted this revision.Oct 24 2017, 2:19 AM

LGTM. Thanks!

This revision is now accepted and ready to land.Oct 24 2017, 2:19 AM
This revision was automatically updated to reflect the committed changes.