This is an archive of the discontinued LLVM Phabricator instance.

[x86/MIR] Implement support for pre- and post-instruction symbols, as well as MIR parsing support for `MCSymbol` `MachineOperand`s.
ClosedPublic

Authored by chandlerc on Aug 16 2018, 1:13 AM.

Details

Summary

The only real way to test pre- and post-instruction symbol support is to
use them in operands, so I ended up implementing that within the patch
as well. I can split out the operand support if folks really want but it
doesn't really seem worth it.

The functional implementation of pre- and post-instruction symbols is
now *completely trivial*. Two tiny bits of code in the (misnamed)
AsmPrinter. It should be completely target independent as well. We emit
these exactly the same way as we emit basic block labels. Most of the
code here is to give full dumping, MIR printing, and MIR parsing support
so that we can write useful tests.

The MIR parsing of MC symbol operands still isn't 100%, as it forces the
symbols to be non-temporary and non-local symbols with names. However,
those names often can encode most (if not all) of the special semantics
desired, and unnamed symbols seem especially annoying to serialize and
de-serialize. While this isn't perfect or full support, it seems plenty
to write tests that exercise usage of these kinds of operands.

The MIR support for pre-and post-instruction symbols was quite
straightforward. I chose to print them out in an as-if-operand syntax
similar to debug locations as this seemed the cleanest way and let me
use nice introducer tokens rather than inventing more magic punctuation
like we use for memoperands.

However, supporting MIR-based parsing of these symbols caused me to
change the design of the symbol support to allow setting arbitrary
symbols. Without this, I don't see any reasonable way to test things
with MIR.

Depends on revision: D50701

Diff Detail

Repository
rL LLVM

Event Timeline

chandlerc created this revision.Aug 16 2018, 1:13 AM
chandlerc updated this revision to Diff 160981.Aug 16 2018, 2:22 AM
chandlerc retitled this revision from [x86/MIR] Add full MIR support for pre- and post-instruction symbols, as well as parsing support for `MCSymbol` `MachineOperand`s. to [x86/MIR] Implement support for pre- and post-instruction symbols, as well as MIR parsing support for `MCSymbol` `MachineOperand`s..
chandlerc edited the summary of this revision. (Show Details)

Update this to be the complete implementation of pre- and post-instruction
symbol emission.

It turned out that implementing the actual emission was 4 lines and is fully
target independent! Win!

I've also included a test that specifically emits this stuff and checks that it
works on x86. Happy for other target maintainers to get tests for their target,
but given the complexity of crafting a MIR test, I'd like to defer that to
folks familiar w/ those backends and motivated to check support here.
Especially given how trivial the actual implementation is here.

I've also improved the MIR parsing test case to double check that we parse back
the *operands* as well as the pre- and post- symbols. I had verified it myself,
but seems important to actually check.

rnk added inline comments.Aug 16 2018, 10:54 AM
llvm/include/llvm/CodeGen/MachineInstr.h
1501–1502 ↗(On Diff #160981)

I still think getOrCreate is the right API for CodeGen. Should this be made private between MachineInstr and MIParser? The only way I can imagine to do that is to introduce some public MIParserHelper class which we forward declare and then define only in the MIParser.cpp file.

llvm/lib/CodeGen/MIRParser/MIParser.cpp
763 ↗(On Diff #160981)

I think it would be more stylistically consistent for this to be a method of MIParser. Something just like parseMachineOperandAndTiedFlags above. I'd also use out parameters to match the error handling style.

llvm/lib/CodeGen/MachineInstr.cpp
507 ↗(On Diff #160981)

That should be fairly easy if every MachineInstr owns its own ExtraInfo. Also, I don't think we're saving much memory from using TrailingObjects for the optional pre and post labels. We might as well make those regular nullable pointer members of ExtraInfo for simplicity. Then, mutating them is pretty straightforward.

chandlerc updated this revision to Diff 161115.Aug 16 2018, 2:47 PM
chandlerc marked an inline comment as done.

Switch to a more conventional code pattern for the parsing based on code review.

llvm/include/llvm/CodeGen/MachineInstr.h
1501–1502 ↗(On Diff #160981)

I think it is useful for the caller to control the way the symbol is created.

For example, it might be specifically desirable for these to be external symbols for some passes.

The caller will still have to find all references to the current symbol and update them if it wants to change the symbol here, but it doesn't seem like the API should block that from happening just because it is hard?

Alternatively, I can make these be a *list* of symbols and emit all of them. That would make it even more usable for supporting different use cases for the symbols. Thoughts?

llvm/lib/CodeGen/MIRParser/MIParser.cpp
763 ↗(On Diff #160981)

Gah. Fine.

I really, really dislike this style which is why I didn't try to emulate it, but I also think you're right.

llvm/lib/CodeGen/MachineInstr.cpp
507 ↗(On Diff #160981)

Folks seemed very concerned about the memory usage of ExtraInfo so I'm happy to keep it optimized for now... I can make them mutable though (or we can allow appending if that helps based on my other comment above). Probably a follow-up patch though?

rnk accepted this revision.Aug 16 2018, 3:26 PM

lgtm

llvm/include/llvm/CodeGen/MachineInstr.h
1501–1502 ↗(On Diff #160981)

I think the external symbol use case is kind of interesting. Fair enough.

llvm/lib/CodeGen/MIRParser/MIParser.cpp
763 ↗(On Diff #160981)

Thanks!

llvm/lib/CodeGen/MachineInstr.cpp
507 ↗(On Diff #160981)

Yeah, a follow-up is fine.

This revision is now accepted and ready to land.Aug 16 2018, 3:26 PM

Thanks for the review!

Landing now, but also happy to keep poking this in follow-ups until everyone is happy.

This revision was automatically updated to reflect the committed changes.

I fixed a couple of issues in https://reviews.llvm.org/rL340034. Let me know if that doesn't work for you.