This is an archive of the discontinued LLVM Phabricator instance.

[M68k] Add support for Motorola literal syntax to AsmParser
ClosedPublic

Authored by ricky26 on Mar 12 2021, 8:54 AM.

Details

Summary

This adds support for parsing Motorola-style integers, which are used by default by the existing compilers for the M68k.

These look like $00A0cf for hex and %001010101 for binary. They are used in Motorola assembly syntax.

There's a possible question about how the binary literals will interact with inline assembly in clang.

Diff Detail

Event Timeline

ricky26 created this revision.Mar 12 2021, 8:54 AM
ricky26 updated this revision to Diff 332005.Mar 19 2021, 2:31 PM

Run clang-format

anirudhp added inline comments.
llvm/include/llvm/MC/MCAsmInfo.h
453

My apologies for intruding into a draft patch :)

Firstly, I don't believe there is anything wrong with introducing a field in MCAsmInfo.h and setting it in the appropriate target inherited version of it.

However, there seems to be previous precedent within MCAsmLexer.h to support a different class of Integers (LexMasmIntegers). So maybe the field could go directly into MCAsmLexer and could be set in AsmLexer/AsmParser as appropriate?

ricky26 published this revision for review.Apr 2 2021, 5:52 AM
ricky26 added inline comments.
llvm/include/llvm/MC/MCAsmInfo.h
453

Hi, there's no problem there. I mostly uploaded this early since it's a dependency for one of my other patches. Feedback is always welcome. :)

I think I might've seen LexMasmIntegers when I was initially implementing this but having just followed it through the code again, I can't see how to make it the default (for example, I'd expect clang -cc1as/llvm-mc/etc to use Motorola-style integers by default for M68k but not anything else).

I'm lament to add specific logic to determine that default in all of the front-ends but it looks like that's what is done with LexMasmIntegers.

I'll open this up for review proper now anyway.

Herald added a project: Restricted Project. · View Herald TranscriptApr 2 2021, 5:52 AM
ricky26 edited the summary of this revision. (Show Details)Apr 2 2021, 6:02 AM

Can you add tests for this?

llvm/lib/MC/MCParser/AsmLexer.cpp
426

0-9a-fA-F? (Currently reads 0-0)

811

I think this only recognizes hex numbers that start with 0-9. Is $ff a valid integer literal in this context? If so, this should maybe use isHexDigit.

ricky26 updated this revision to Diff 334950.Apr 2 2021, 7:17 AM

Apply review feedback, add some tests and a flag for llvm-mc.

ricky26 marked 2 inline comments as done.Apr 2 2021, 7:20 AM
epastor accepted this revision.Apr 2 2021, 7:49 AM
This revision is now accepted and ready to land.Apr 2 2021, 7:49 AM
anirudhp added inline comments.Apr 2 2021, 10:27 AM
llvm/lib/MC/MCParser/AsmLexer.cpp
36

If you're setting this in the constructor, I'm hoping you're aware that for any other invocations of the AsmParser instance, except from llvm-mc, the lexing of motorola integers will not work as "expected", until the UseMotorolaIntegers attribute is explicitly set in the Motorola's inherited version of MCAsmInfo

If the only intended invocation is from llvm-mc for now, then maybe it makes sense to remove the MCAsmInfo attribute completely, since you already declared LexMotorolaIntegers as LexMotorolaIntegers = false in MCAsmLexer.h.

ricky26 added inline comments.Apr 2 2021, 10:37 AM
llvm/lib/MC/MCParser/AsmLexer.cpp
36

That's about the size of it. I kept it this way so that I can happily build tests for this piece of functionality (which affects more than just the experimental platform) without building for M68k. Then, when the M68k AsmParser implementation lands, it'll include the change to M68kMCAsmInfo.

I wanted to keep the MCAsmInfo change here to avoid bundling changes into the already quite large bootstrapping of the M68k assembler.

It feels a bit off to populate this in the constructor as I've done, so I'm very much open to alternatives.

anirudhp added inline comments.Apr 2 2021, 10:50 AM
llvm/lib/MC/MCParser/AsmLexer.cpp
36

I wanted to keep the MCAsmInfo change here to avoid bundling changes into the already quite large bootstrapping of the M68k assembler.

Hmm I see. I guess the only other suggestion I have in this case, is to have a small patch that just deals with setting the MCAsminfo changes, and the setting of the variable in the MCAsmLexer constructor, and have your big asm parser patch depend on that.

But at the same time that might be just increasing your work unnecessarily :), and if the particular attribute is going to be set soon in a forthcoming patch, then it should be fine to have your changes in this patch the way they are currently.

ricky26 updated this revision to Diff 335049.Apr 2 2021, 5:15 PM

Pulled the use of UseMotorolaIntegers back into this patch.

It ocurred to me that it can't actually have any negative effects since there's
no means in tree to instantiate an AsmParser for the M68k yet.

myhsu accepted this revision.Apr 4 2021, 11:00 PM
myhsu added inline comments.
llvm/lib/MC/MCParser/AsmLexer.cpp
36

I ca definitely foresee a more modular changes if we split the MCAsmInfo attribute and the populating LexMotorolaIntegers in constructor into a separate patch. But to be honest I feel like this is a really minor software engineering issue.
It will only concern me if reverting any of these patches causes large scale disaster. But either we split this patch or not, M68k will be the only one get affected. So I'm fine with the current arrangement.