This is an archive of the discontinued LLVM Phabricator instance.

[M68k] Add parsing support for more operand types
Needs ReviewPublic

Authored by ricky26 on Aug 26 2021, 5:25 AM.

Details

Summary

Fixes PR49862.

This adds parsing support for the remaining address modes:

  • address register indirect w/ index (with size & scale)
  • memory indirect (pre- & post-indexed)

Some of these are not supported by codegen yet.

Diff Detail

Event Timeline

ricky26 created this revision.Aug 26 2021, 5:25 AM
ricky26 requested review of this revision.Aug 26 2021, 5:25 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 26 2021, 5:25 AM

I'd prefer to see the style changes separated out, there are a few too many for me to be bundled with functional changes, and there are places where it takes a moment to check whether something's a functional change or not.

llvm/lib/Target/M68k/AsmParser/M68kAsmParser.cpp
86

Needs rebasing to use KindTy

268

This kind of thing seems like a bad idea, just asking for expressions to go missing and get silently converted to 0. The places where this can happen should really be creating an MCConstantExpr of 0.

325

Ditto

llvm/test/MC/M68k/instructions.s
1

Don't combine error and non-error cases in the same test, otherwise there could be errors triggered by the believed-non-error cases that you fail to catch

14

This is... really weird. I don't think it makes any sense to add parsing before it can actually be used for anything.

64

That probably means you shouldn't be supporting parsing them yet. Also CodeGen its above the MC layer, not below it, so what CodeGen does is irrelevant. The issue is the lack of MC support, not a lack of CodeGen patterns.

ricky26 added inline comments.Aug 26 2021, 6:02 AM
llvm/lib/Target/M68k/AsmParser/M68kAsmParser.cpp
86

Actually, that's a different enum. KindTy is in M68kOperand. Perhaps I should rename this one too?

268

I agree but at the moment this is working as a mechanism to preserve the existing functionality.

Ideally we should pick ARII/ARID instructions based on whether the displacement is 0, rather than null. However, that causes a lot of changes to tests and particularly sometimes causes the assembler to pick a 'worse' instruction (using an ARID instruction when an ARII one exists).

I put a couple of comments elsewhere in the file which I hoped covered this sentiment.

llvm/test/MC/M68k/instructions.s
14

That's fair - I implemented them as I was going through the checklist for all the addressing modes in the CPU manual (the additional addressing modes were fallout from the initial AsmParser work). I figured that completeness for this one section (even without MC support) would be more beneficial than the smaller patch with just the ones we can currently support. I expected we were going to need the MC part for the backend to graduate from experimental anyway.

I did consider adding the relevant move instruction formats in a separate patch first but I'm lament to add to that area whilst (at least in my mind) there's still a bit of a sword of Damocles hanging over the instruction representation in the tablegen files.

jrtc27 added inline comments.Aug 26 2021, 6:04 AM
llvm/lib/Target/M68k/AsmParser/M68kAsmParser.cpp
86

Oh right. This one's fine, the variable's called Op so no conflicts.

myhsu added a comment.Aug 26 2021, 1:42 PM

Thank you for taking a look into this :-)
If we use the addressing mode designators listed here, I think the problem here is that you want to implement asm parsing logic for 'v', 'u', and 'g'. But we don't even have those addressing modes in the instruction definitions yet (almost all supported addressing modes are listed here).
I prefer to have complete codegen + asm parsing support for these three addressing modes instead of only the asm parsing part as presented here. You can, for example, have three separate patches in which each of them contains full support for one of the said addressing modes.

Fair enough, makes good sense. I was trying to chip away at things which didn't involve messing with the instruction definitions (since they feel a little up in the air still).

Either way I can shelve these for now and reconstitute them into separate patches at a later date along with the relevant functionality.

Thanks all for the feedback. :)

I might post a message on the llvm-dev mailing list asking about some of the next steps.