[M68k] Use M68010 cpu as target for SR move test #122452

TechnoElf · 2025-01-10T13:20:25Z

Fixes the test introduced in #111145.

It would also make sense to throw an error when the user attempts to use a move-from-sr on an unsupported architecture. Currently the encoder generates garbage instructions for a 68000 because the AsmMatcher is able to match the move against a MOV16rr:

> llvm-mc -triple=m68k -mcpu=M68000 -show-encoding MxMoveSR.s --debug
...
Trying to match opcode MOV16ar
  Matching formal operand class MCK_Reg against actual operand at index 1 (%7): match success using generic matcher
  Matching formal operand class MCK_AReg against actual operand at index 2 (%25): Opcode result: multiple operand mismatches, ignoring this opcode
Trying to match opcode MOV16rr
  Matching formal operand class MCK_Reg against actual operand at index 1 (%7): match success using generic matcher
  Matching formal operand class MCK_Reg against actual operand at index 2 (%25): match success using generic matcher
  Matching formal operand class InvalidMatchClass against actual operand at index 3: actual operand index out of range
Opcode result: complete match, selecting this opcode
EncodeInstruction: MOV16rr(901)
        move.w  %sr, %d1                        ; encoding: [0x32,0x00]

I haven't found a solution for this yet, so any ideas you have would be greatly appreciated.

@mshockwave @knickish

llvmbot · 2025-01-10T14:12:18Z

@llvm/pr-subscribers-mc

@llvm/pr-subscribers-backend-m68k

Author: Janis Heims (TechnoElf)

Changes

Fixes the test introduced in #111145.

It would also make sense to throw an error when the user attempts to use a move-from-sr on an unsupported architecture. Currently the encoder generates garbage instructions for a 68000 because the AsmMatcher is able to match the move against a MOV16rr:

&gt; llvm-mc -triple=m68k -mcpu=M68000 -show-encoding MxMoveSR.s --debug
...
Trying to match opcode MOV16ar
  Matching formal operand class MCK_Reg against actual operand at index 1 (%7): match success using generic matcher
  Matching formal operand class MCK_AReg against actual operand at index 2 (%25): Opcode result: multiple operand mismatches, ignoring this opcode
Trying to match opcode MOV16rr
  Matching formal operand class MCK_Reg against actual operand at index 1 (%7): match success using generic matcher
  Matching formal operand class MCK_Reg against actual operand at index 2 (%25): match success using generic matcher
  Matching formal operand class InvalidMatchClass against actual operand at index 3: actual operand index out of range
Opcode result: complete match, selecting this opcode
EncodeInstruction: MOV16rr(901)
        move.w  %sr, %d1                        ; encoding: [0x32,0x00]

I haven't found a solution for this yet, so any ideas you have would be greatly appreciated.

@mshockwave @knickish

Full diff: https://github.com/llvm/llvm-project/pull/122452.diff

1 Files Affected:

(modified) llvm/test/MC/M68k/Data/Classes/MxMoveSR.s (+1-1)

diff --git a/llvm/test/MC/M68k/Data/Classes/MxMoveSR.s b/llvm/test/MC/M68k/Data/Classes/MxMoveSR.s
index 03189311badb8e..e999345f43fc3e 100644
--- a/llvm/test/MC/M68k/Data/Classes/MxMoveSR.s
+++ b/llvm/test/MC/M68k/Data/Classes/MxMoveSR.s
@@ -1,4 +1,4 @@
-; RUN: llvm-mc -triple=m68k -mcpu=M68000 -show-encoding %s | FileCheck %s
+; RUN: llvm-mc -triple=m68k -mcpu=M68010 -show-encoding %s | FileCheck %s
 
 ; CHECK:      move.w  %d1, %sr
 ; CHECK-SAME: encoding: [0x46,0xc1]

knickish · 2025-01-10T14:12:26Z

Ah, I had not realized that was the issue. I don't have the bandwidth to work on this (immediately at least), do you think this is best handled with this patch or a revert?

TechnoElf · 2025-01-10T15:11:28Z

I guess we can patch the test for now and add proper errors later. This affects move-from-ccr as well, so it'd probably be better to make a separate patch for that anyway.

mgorny

LGTM. Let's either merge this or revert the original change. Having tests broken for 2 days is not nice.

llvm-ci · 2025-01-11T14:33:57Z

LLVM Buildbot has detected a new failure on builder llvm-clang-x86_64-expensive-checks-debian running on gribozavr4 while building llvm at step 6 "test-build-unified-tree-check-all".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/16/builds/11824

Here is the relevant piece of the build log for the reference

Step 6 (test-build-unified-tree-check-all) failure: test (failure)
******************** TEST 'LLVM :: tools/llvm-gsymutil/ARM_AArch64/macho-merged-funcs-dwarf.yaml' FAILED ********************
Exit Code: 1

Command Output (stdout):
--
Input file: /b/1/llvm-clang-x86_64-expensive-checks-debian/build/test/tools/llvm-gsymutil/ARM_AArch64/Output/macho-merged-funcs-dwarf.yaml.tmp.dSYM
Output file (aarch64): /b/1/llvm-clang-x86_64-expensive-checks-debian/build/test/tools/llvm-gsymutil/ARM_AArch64/Output/macho-merged-funcs-dwarf.yaml.tmp.default.gSYM
Loaded 3 functions from DWARF.
Loaded 3 functions from symbol table.
warning: same address range contains different debug info. Removing:
[0x0000000000000248 - 0x0000000000000270): Name=0x00000001
addr=0x0000000000000248, file=  1, line=  5
addr=0x0000000000000254, file=  1, line=  7
addr=0x0000000000000258, file=  1, line=  9
addr=0x000000000000025c, file=  1, line=  8
addr=0x0000000000000260, file=  1, line= 11
addr=0x0000000000000264, file=  1, line= 10
addr=0x0000000000000268, file=  1, line=  6


In favor of this one:
[0x0000000000000248 - 0x0000000000000270): Name=0x00000047
addr=0x0000000000000248, file=  3, line=  5
addr=0x0000000000000254, file=  3, line=  7
addr=0x0000000000000258, file=  3, line=  9
addr=0x000000000000025c, file=  3, line=  8
addr=0x0000000000000260, file=  3, line= 11
addr=0x0000000000000264, file=  3, line= 10
addr=0x0000000000000268, file=  3, line=  6


warning: same address range contains different debug info. Removing:
[0x0000000000000248 - 0x0000000000000270): Name=0x00000047
addr=0x0000000000000248, file=  3, line=  5
addr=0x0000000000000254, file=  3, line=  7
addr=0x0000000000000258, file=  3, line=  9
addr=0x000000000000025c, file=  3, line=  8
addr=0x0000000000000260, file=  3, line= 11
addr=0x0000000000000264, file=  3, line= 10
addr=0x0000000000000268, file=  3, line=  6


In favor of this one:
[0x0000000000000248 - 0x0000000000000270): Name=0x00000030
addr=0x0000000000000248, file=  2, line=  5
addr=0x0000000000000254, file=  2, line=  7
addr=0x0000000000000258, file=  2, line=  9
addr=0x000000000000025c, file=  2, line=  8
addr=0x0000000000000260, file=  2, line= 11
addr=0x0000000000000264, file=  2, line= 10
...

llvm-ci · 2025-01-11T14:53:29Z

LLVM Buildbot has detected a new failure on builder openmp-s390x-linux running on systemz-1 while building llvm at step 6 "test-openmp".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/88/builds/6678

Here is the relevant piece of the build log for the reference

Step 6 (test-openmp) failure: 1200 seconds without output running [b'ninja', b'-j 4', b'check-openmp'], attempting to kill
...
PASS: ompd-test :: openmp_examples/example_3.c (439 of 449)
PASS: ompd-test :: openmp_examples/example_4.c (440 of 449)
PASS: ompd-test :: openmp_examples/example_5.c (441 of 449)
PASS: ompd-test :: openmp_examples/example_task.c (442 of 449)
UNSUPPORTED: ompd-test :: openmp_examples/ompd_bt.c (443 of 449)
PASS: ompd-test :: openmp_examples/fibonacci.c (444 of 449)
UNSUPPORTED: ompd-test :: openmp_examples/ompd_parallel.c (445 of 449)
PASS: ompd-test :: openmp_examples/parallel.c (446 of 449)
PASS: ompd-test :: openmp_examples/nested.c (447 of 449)
PASS: ompd-test :: openmp_examples/ompd_icvs.c (448 of 449)
command timed out: 1200 seconds without output running [b'ninja', b'-j 4', b'check-openmp'], attempting to kill
process killed by signal 9
program finished with exit code -1
elapsedTime=1323.875847

Fixes the test introduced in llvm#111145. It would also make sense to throw an error when the user attempts to use a move-from-sr on an unsupported architecture. Currently the encoder generates garbage instructions for a 68000 because the AsmMatcher is able to match the move against a MOV16rr

[M68k] Use 68010 cpu as target for SR move test

ebe0eec

TechnoElf mentioned this pull request Jan 10, 2025

[M68k] implement move to and from sr #111145

Merged

TechnoElf marked this pull request as ready for review January 10, 2025 14:11

llvmbot added mc Machine (object) code backend:m68k labels Jan 10, 2025

mgorny approved these changes Jan 11, 2025

View reviewed changes

knickish merged commit ba58d35 into llvm:main Jan 11, 2025
13 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[M68k] Use M68010 cpu as target for SR move test #122452

[M68k] Use M68010 cpu as target for SR move test #122452

Uh oh!

TechnoElf commented Jan 10, 2025

Uh oh!

llvmbot commented Jan 10, 2025 •

edited

Loading

Uh oh!

knickish commented Jan 10, 2025

Uh oh!

TechnoElf commented Jan 10, 2025

Uh oh!

mgorny left a comment

Uh oh!

Uh oh!

llvm-ci commented Jan 11, 2025

Uh oh!

llvm-ci commented Jan 11, 2025

Uh oh!

Uh oh!

[M68k] Use M68010 cpu as target for SR move test #122452

[M68k] Use M68010 cpu as target for SR move test #122452

Uh oh!

Conversation

TechnoElf commented Jan 10, 2025

Uh oh!

llvmbot commented Jan 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

knickish commented Jan 10, 2025

Uh oh!

TechnoElf commented Jan 10, 2025

Uh oh!

mgorny left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

llvm-ci commented Jan 11, 2025

Uh oh!

llvm-ci commented Jan 11, 2025

Uh oh!

Uh oh!

llvmbot commented Jan 10, 2025 •

edited

Loading