[NFC] Combine README of test/CodeGen/M68k with the one in test/CodeGen/M68k/Encoding

• Addressed feedbacks

• Addressed feedbacks

• [NFC] Addressed feedbacks

• Addressed feedbacks

• Addressed feedbacks

• [NFC] Addressed feedbacks

• Addressed feedbacks

In D88392#2560868, @jrtc27 wrote:

As I've said before, please use update_llc_test_checks.py. Manually-maintained CHECK lines are a complete pain when making tree-wide changes.

• Use update_llc_test_checks.py to manage all the assembly tests

• Addressed feedbacks

• [NFC] Addressed some of the feedbacks

• [NFC] Addressed feedbacks

• [NFC] Remove reset of the x00 prefixes

• [NFC] Rename CHECK prefixes
  • Replace any standalone x00 prefix with normal CHECK
  • Capitalize custom prefix

• [NFC] Addressed most of the feedbacks

• Addressed feedbacks

• Reflecting changes from D88391 on optimizing multiplications

• Addressed feedbacks
  • Use TargetLowering callback to optimize multiplications instead of doing manually

• Addressed feedback
  • Remove redundant target macro definitions

• Addressed feedbacks

• Addressed feedbacks
  • Now M68k tries to use ABI that is compatible with GCC

• Addressed feedbacks
  • Split the problems found in ASM/Arith/imul.ll into a separate test case ASM/Arith/imul-neg.ll and mark XFAIL for now

• Addressed some of the feedbacks

• [NFC] Addressed feedbacks

In D88390#2530647, @rengolin wrote:

In D88390#2529089, @myhsu wrote:

We don't have AsmParser and disassembler right now. We're using MIR as input to test our integrated assembler, so you're right, we can't test MC layer without CodeGen. But why would that will be a hard blocker?

The real requirement is being able to produce code at the end. If that relies on (free, accessible) third-party tools, then it should be find for the first import. Some production targets have (free) proprietary tools that are required to continue the code generation (ex. NVPTX). Other targets have assemblers but can be tested (no available hardware). Having specific hard requirements would make it really hard for LLVM to have new backends.

In D88390#2528951, @jrtc27 wrote:

So, uh, correct me if I'm wrong but none of these patches add assembler or disassembler support? Should that not be present before a target is accepted? Otherwise there's no way to test any of the MC layer without including CodeGen.

• [NFC] Fixed formatting

• Addressed feedbacks

In D88385#2518064, @RKSimon wrote:

@myhsu I think you will also need a Patch 0/8 - adding you as the m68k code owner :)

• Addressed feedbacks
  • And the synergy header comment changes from 88390

Can you also link patch 1~3 as the related revisions as well?

• [NFC] Addressed feedbacks
  • Use atLeastM68020, atLeastM68030...etc to replace isM68020, isM68030...etc

• [NFC] Addressed feedbacks

• [NFC] Fixed minor formatting issue

• Addressed feedbacks

• Addressed feedbacks

In D88385#2506204, @RKSimon wrote:

In D88385#2505260, @jrtc27 wrote:

In D88385#2505204, @RKSimon wrote:

Thanks @myhsu!

@jrtc27 - you're still blocking this - is there anything else you think we need to address here?

For this review, no. There are a bunch of outstanding issues on the other reviews though that need addressing; I don't know if it makes sense to land this now or wait and land them all in one go once the other reviews are fixed and approved.

The plan is for the entire patch series to be accepted before any are pushed.

In D88385#2503250, @rengolin wrote:

In D88385#2502299, @myhsu wrote:

Absolutely. I agree this problem should be solve before graduate from experimental target. I will create these bugs soon

You could also create a meta bug called something like "m68k in production" that all bugs that needed to be solved before we move the target to production are dependencies.

People filling bugs against the target can link to that meta bug if the issue is serious enough.

You could also create infrastructure bugs like creating buildbots, passing certain milestones in compiling programs and OSs, etc.

It'd be easy then to see that the target is good enough to be promoted to production once all those bugs (or at least all critical ones) are solved.

In D88385#2502280, @RKSimon wrote:

@myhsu Please can you raise a bug covering the CodeBeads vs TSFlags refactor options and make it a blocker against a second bug for making the m68k backend non-experimental?

In D88385#2476359, @Paul-C-Anagnostopoulos wrote:

I was thinking of using a bit in the other flags member, Flags, as opposed to TSFlags. Then there would be nothing sneaky going on in the union itself.

Making it an anonymous union would mean that all current references to TSFlags would still work, correct?

In D88385#2476327, @jrtc27 wrote:

In D88385#2476326, @myhsu wrote:

In D88385#2476220, @Paul-C-Anagnostopoulos wrote:

If it isn't possible to encode the information in TSFlags, another possibility is to add a pointer to the MCInstrDesc class that points to some kind of auxiliary class/struct.

This actually gives me an idea to directly use the MCInstrDesc::TSFlags as a pointer to auxiliary data structures. That is:

auto* AuxTable =  reinterpret_cast<uint8_t*>(MD.TSFlags);

Definitely not. Integers are not pointers, and will break on CHERI. You would need to make TSFlags a uintptr_t if you want that to work, but then you only get 32 bits on 32-bit architectures.

In D88385#2476167, @RKSimon wrote:

Do you have any idea how much work would be necessary for the TSFlags refactor?

In D88385#2475335, @jrtc27 wrote:

I still don't understand what problem code beads are trying to solve that isn't already solved by existing backends like X86. Why can't you just assign operands to instruction encoding bits like a normal backend?

• [NFC] Addressed some of the feedbacks
  • Need to double check the comments related to Clang part changes and pointer size

• Addressed some of the feedbacks
  • I need a little more time double checking the (motorola) assembly syntax

• [NFC] Addressed feedbacks

Fixed incorrect formats (redundant commas) when printing move mask

• Addressed some of the feedbacks
• [NFC] Removed '#<number>' in the comments
• [NFC] Fixed minor formatting issues

• [NFC] Remove all '#<number>' TODO/FIXME comments (they were ticket number from legacy issue tracker) and add more meaningful comments/explanations
• [NFC] Add more explanation on building LLVM natively on M68k (i.e. the alignment issue)
  • Eventually I still decide to ship native build support on M68k via -malign-int flag since it still works in some M68k CPUs w/ 32-bit bus, albeit not all of the models

It turns out I've already committed this at the same time with changes in llvm-test (after @lebedev.ri approved this) and I totally forgot about it :-P
https://github.com/llvm/llvm-project/commit/bd5fe7b010ea0d6c4b1e5e3740085f5eabf7def6

In D88868#2445067, @RKSimon wrote:

In D88868#2443692, @myhsu wrote:

In D88868#2442287, @lebedev.ri wrote:

I don't believe this needs libc++'s signoff, it only mechanically replicates
the exact same change to the same external dependency into all the duplicate copies of said dependency.
@myhsu i still maintain that you can just commit this now.

As @ldionne mentioned libcxx was added automatically and I couldn't remove it. Otherwise I've already committed this patch a while ago: https://github.com/llvm/llvm-test-suite/commit/25883edc2f615a84c4fa741e997904293474bbc0

Isn't that just testsuite's copy of the code from D89011? It looks like at least the libcxx parts of this patch still need committing.

• [NFC] Fix minor formatting

• Rewrite utils/extract-section into utils/extract-section.py
  • The new Python script is also more generic which doesn't have some M68k specific assumption (e.g. always group in 16-bits in hex mode) as the previous version
• Update M68k-local LIT config

• [NFC] Fix formatting

• Rebase to latest changes
• Addressed feedbacks

In D88868#2442287, @lebedev.ri wrote:

I don't believe this needs libc++'s signoff, it only mechanically replicates
the exact same change to the same external dependency into all the duplicate copies of said dependency.
@myhsu i still maintain that you can just commit this now.

• Update test cases related to 8-bit multiplications.

• Fix ISel failure when it comes to 8-bit multiplications

• Add support for M68060 sub-target

• Add support for M68060 sub-target

• Add M68060 sub-target

• Add M68060 sub-target
  • Our original plan was to add this after the current patch series got flushed out. But after reading the feedbacks, and due to the fact that M68060 doesn't have major ISA difference with M68040, we decided to add the sub-target skeleton now and fill in the details later.

• Fix / Update failed test cases. Now we have 100% passing rate except one XFAIL, yeah!
  • Most of the previous failed test cases were caused by less-optimal results from previous version of codegen. For example, the codegen for jump tables.
  • The only XFAIL is caused by (selection DAG) ISel which failed to select one instruction that supposed to have 16-bit operand but a 8-bit one was given. It seems to take more time to fix it so just mark XFAIL for now

• Re-enable analyzeBranch implementation
  • Skip if the branch target is an immediate value, which is rare in real world cases but essential for some of the binary encoding test cases.

• Fix incorrect relaxation decision

• Addressed all the feedbacks
• Fixed minor issues that would retrieve the wrong TargetCodeGenInfo instance

• Rebased to latest changes
• Addressed some of the feedbacks