Thanks to visit codestin.com
Credit goes to github.com

Skip to content

ARM: Remove override of shouldRewriteCopySrc #125219

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
May 5, 2025

Conversation

arsenm
Copy link
Contributor

@arsenm arsenm commented Jan 31, 2025

All of the overrides of shouldRewriteCopySrc appear to be hacks
for bugs in the base implementation, so I'm trying to delete
all of the overrides. I was expecting this to find an example
issue like the x86 version, but no tests change with this.

Copy link
Contributor Author

arsenm commented Jan 31, 2025

This stack of pull requests is managed by Graphite. Learn more about stacking.

@arsenm arsenm marked this pull request as ready for review January 31, 2025 13:52
@llvmbot
Copy link
Member

llvmbot commented Jan 31, 2025

@llvm/pr-subscribers-backend-arm

Author: Matt Arsenault (arsenm)

Changes

All of the overrides of shouldRewriteCopySrc appear to be hacks
for bugs in the base implementation, so I'm trying to delete
all of the overrides. I was expecting this to find an example
issue like the x86 version, but no tests change with this.


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

2 Files Affected:

  • (modified) llvm/lib/Target/ARM/ARMBaseRegisterInfo.cpp (-14)
  • (modified) llvm/lib/Target/ARM/ARMBaseRegisterInfo.h (-5)
diff --git a/llvm/lib/Target/ARM/ARMBaseRegisterInfo.cpp b/llvm/lib/Target/ARM/ARMBaseRegisterInfo.cpp
index 22ebe175ff62fc..d52903eb906b98 100644
--- a/llvm/lib/Target/ARM/ARMBaseRegisterInfo.cpp
+++ b/llvm/lib/Target/ARM/ARMBaseRegisterInfo.cpp
@@ -942,17 +942,3 @@ bool ARMBaseRegisterInfo::shouldCoalesce(MachineInstr *MI,
   }
   return false;
 }
-
-bool ARMBaseRegisterInfo::shouldRewriteCopySrc(const TargetRegisterClass *DefRC,
-                                               unsigned DefSubReg,
-                                               const TargetRegisterClass *SrcRC,
-                                               unsigned SrcSubReg) const {
-  // We can't extract an SPR from an arbitary DPR (as opposed to a DPR_VFP2).
-  if (DefRC == &ARM::SPRRegClass && DefSubReg == 0 &&
-      SrcRC == &ARM::DPRRegClass &&
-      (SrcSubReg == ARM::ssub_0 || SrcSubReg == ARM::ssub_1))
-    return false;
-
-  return TargetRegisterInfo::shouldRewriteCopySrc(DefRC, DefSubReg,
-                                                  SrcRC, SrcSubReg);
-}
diff --git a/llvm/lib/Target/ARM/ARMBaseRegisterInfo.h b/llvm/lib/Target/ARM/ARMBaseRegisterInfo.h
index 68a28043fd32ec..37c27f26eb04a1 100644
--- a/llvm/lib/Target/ARM/ARMBaseRegisterInfo.h
+++ b/llvm/lib/Target/ARM/ARMBaseRegisterInfo.h
@@ -159,11 +159,6 @@ class ARMBaseRegisterInfo : public ARMGenRegisterInfo {
                       const TargetRegisterClass *NewRC,
                       LiveIntervals &LIS) const override;
 
-  bool shouldRewriteCopySrc(const TargetRegisterClass *DefRC,
-                            unsigned DefSubReg,
-                            const TargetRegisterClass *SrcRC,
-                            unsigned SrcSubReg) const override;
-
   int getSEHRegNum(unsigned i) const { return getEncodingValue(i); }
 };
 

@arsenm
Copy link
Contributor Author

arsenm commented Jan 31, 2025

X86 version in #125224

Copy link
Collaborator

@qcolombet qcolombet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which change in the peephole optimizer specifically removes the need for this workaround?

@arsenm
Copy link
Contributor Author

arsenm commented Feb 1, 2025

Which change in the peephole optimizer specifically removes the need for this workaround?

#125224, but the ARM change doesn't depend on that

@davemgreen
Copy link
Collaborator

From what I can tell if we peephole to these 'invalid' copies, like this patch does, the register coalescer will come along and add them in again. I'm not sure if that always happens though or whether it is worth combining them together, I haven't seen anywhere where this causes problems. Do you have a reason to remove this? The case I came up with where this did change things it made them better by removing some copies via gprs.

@arsenm
Copy link
Contributor Author

arsenm commented Feb 3, 2025

From what I can tell if we peephole to these 'invalid' copies,

No optimization is allowed to introduce illegal copies. This is supposed to be an optimization hint, the target isn't supposed to be responsible for avoiding invalid code here.

Do you have a reason to remove this?

I'm pretty sure the existence of this is a hack (I added the hook in the first place), and not having purely generic logic may complicate another fix I'm working on.

The case I came up with where this did change things it made them better by removing some copies via gprs.

Then that needs to be reflected in a testcase. If code can be deleted and no test change, it should be deleted

@davemgreen
Copy link
Collaborator

Yep I agree - presumably the tests for this problem are no longer hitting the same issue due to other changes.

As far as I understand the issue - Arm has d registers that overlap with s registers, so s0+s1 == d0 and s2+s3 == d1 etc. There are 32 s registers, which alias the first 16 d registers. But (with the right features) there are 32 d registers, the top/bottom half of which have no corresponding s regs, so a dpr + subreg -> reg copy is not valid if an upper d reg is used.

The best test case I came up with was https://godbolt.org/z/4vGKaTr4s, which for this patch produced one of those copies, but it was later relaxed into two.

@arsenm arsenm force-pushed the users/arsenm/arm/remove-shouldRewriteCopySrc branch 2 times, most recently from c058c3e to 0096a5d Compare May 3, 2025 07:20
@arsenm
Copy link
Contributor Author

arsenm commented May 3, 2025

The best test case I came up with was https://godbolt.org/z/4vGKaTr4s, which for this patch produced one of those copies, but it was later relaxed into two.

I see this did change, but the result looks better? It's fewer real instructions. I added the test as a baseline. I can submit that separately if the old result was really better.

Copy link
Collaborator

@davemgreen davemgreen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I understand this will start creating "illegal" copies that are not themselves supported (they go from high dregs+subreg to sregs, which isn't a valid copy). They are turned back into p pair of copies later on though, so it doesn't seem to be an issue in practice. If you are happy with it working like that then I am happy to give this a go and we can see if it leads to issues elsewhere.

LGTM

arsenm added a commit that referenced this pull request May 5, 2025
arsenm added 2 commits May 5, 2025 18:08
All of the overrides of shouldRewriteCopySrc appear to be hacks
for bugs in the base implementation, so I'm trying to delete
all of the overrides. I was expecting this to find an example
issue like the x86 version, but no tests change with this.
@arsenm arsenm force-pushed the users/arsenm/arm/remove-shouldRewriteCopySrc branch from 0096a5d to 96884a6 Compare May 5, 2025 16:09
@arsenm
Copy link
Contributor Author

arsenm commented May 5, 2025

As far as I understand this will start creating "illegal" copies that are not themselves supported (they go from high dregs+subreg to sregs, which isn't a valid copy).

The code here is only trying to avoid potentially expensive cross register bank copies. The details of how a COPY is implemented later aren't so important, so long as the movs we end up with after expansion isn't more expensive

@arsenm arsenm merged commit 9d90f8b into main May 5, 2025
11 checks passed
@arsenm arsenm deleted the users/arsenm/arm/remove-shouldRewriteCopySrc branch May 5, 2025 17:57
@llvm-ci
Copy link
Collaborator

llvm-ci commented May 5, 2025

LLVM Buildbot has detected a new failure on builder lldb-x86_64-debian running on lldb-x86_64-debian while building llvm at step 6 "test".

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

Here is the relevant piece of the build log for the reference
Step 6 (test) failure: build (failure)
...
PASS: lldb-api :: functionalities/thread/concurrent_events/TestConcurrentManyCrash.py (165 of 2888)
PASS: lldb-api :: tools/lldb-server/TestGdbRemoteExitCode.py (166 of 2888)
PASS: lldb-api :: types/TestShortTypeExpr.py (167 of 2888)
PASS: lldb-api :: commands/process/attach-resume/TestAttachResume.py (168 of 2888)
PASS: lldb-api :: functionalities/thread/step_until/TestStepUntil.py (169 of 2888)
PASS: lldb-api :: functionalities/jitloader_gdb/TestJITLoaderGDB.py (170 of 2888)
PASS: lldb-api :: types/TestCharTypeExpr.py (171 of 2888)
PASS: lldb-api :: python_api/type/TestTypeList.py (172 of 2888)
PASS: lldb-api :: lang/cpp/static_members/TestCPPStaticMembers.py (173 of 2888)
UNRESOLVED: lldb-api :: tools/lldb-dap/stackTrace/TestDAP_stackTrace.py (174 of 2888)
******************** TEST 'lldb-api :: tools/lldb-dap/stackTrace/TestDAP_stackTrace.py' FAILED ********************
Script:
--
/usr/bin/python3 /home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/test/API/dotest.py -u CXXFLAGS -u CFLAGS --env LLVM_LIBS_DIR=/home/worker/2.0.1/lldb-x86_64-debian/build/./lib --env LLVM_INCLUDE_DIR=/home/worker/2.0.1/lldb-x86_64-debian/build/include --env LLVM_TOOLS_DIR=/home/worker/2.0.1/lldb-x86_64-debian/build/./bin --arch x86_64 --build-dir /home/worker/2.0.1/lldb-x86_64-debian/build/lldb-test-build.noindex --lldb-module-cache-dir /home/worker/2.0.1/lldb-x86_64-debian/build/lldb-test-build.noindex/module-cache-lldb/lldb-api --clang-module-cache-dir /home/worker/2.0.1/lldb-x86_64-debian/build/lldb-test-build.noindex/module-cache-clang/lldb-api --executable /home/worker/2.0.1/lldb-x86_64-debian/build/./bin/lldb --compiler /home/worker/2.0.1/lldb-x86_64-debian/build/./bin/clang --dsymutil /home/worker/2.0.1/lldb-x86_64-debian/build/./bin/dsymutil --make /usr/bin/gmake --llvm-tools-dir /home/worker/2.0.1/lldb-x86_64-debian/build/./bin --lldb-obj-root /home/worker/2.0.1/lldb-x86_64-debian/build/tools/lldb --lldb-libs-dir /home/worker/2.0.1/lldb-x86_64-debian/build/./lib -t /home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/test/API/tools/lldb-dap/stackTrace -p TestDAP_stackTrace.py
--
Exit Code: 1

Command Output (stdout):
--
lldb version 21.0.0git (https://github.com/llvm/llvm-project.git revision 9d90f8ba7113fd9c7b2662682ad94b744ed2b78c)
  clang revision 9d90f8ba7113fd9c7b2662682ad94b744ed2b78c
  llvm revision 9d90f8ba7113fd9c7b2662682ad94b744ed2b78c
Skipping the following test categories: ['libc++', 'dsym', 'gmodules', 'debugserver', 'objc']

--
Command Output (stderr):
--
Change dir to: /home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/test/API/tools/lldb-dap/stackTrace
runCmd: settings clear --all

output: 

runCmd: settings set symbols.enable-external-lookup false

output: 

runCmd: settings set target.inherit-tcc true

output: 

runCmd: settings set target.disable-aslr false

output: 

runCmd: settings set target.detach-on-error false

output: 

runCmd: settings set target.auto-apply-fixits false

@llvm-ci
Copy link
Collaborator

llvm-ci commented May 5, 2025

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/18417

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 :: CodeGen/ARM/shouldRewriteCopySrc.ll' FAILED ********************
Exit Code: 2

Command Output (stderr):
--
/b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/llc -mtriple=arm-none-eabihf -mcpu=cortex-a55 < /b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/test/CodeGen/ARM/shouldRewriteCopySrc.ll | /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/FileCheck /b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/test/CodeGen/ARM/shouldRewriteCopySrc.ll # RUN: at line 2
+ /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/FileCheck /b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/test/CodeGen/ARM/shouldRewriteCopySrc.ll
+ /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/llc -mtriple=arm-none-eabihf -mcpu=cortex-a55

# After Peephole Optimizations
# Machine code for function shouldRewriteCopySrc: IsSSA, TracksLiveness
Function Live Ins: $d0 in %0

bb.0.bb:
  liveins: $d0
  %0:dpr = COPY $d0
  %1:dpr = VADDD %0:dpr, %0:dpr, 14, $noreg
  INLINEASM &nop [sideeffect] [attdialect], $0:[clobber], implicit-def early-clobber $q0, $1:[clobber], implicit-def early-clobber $q1, $2:[clobber], implicit-def early-clobber $q2, $3:[clobber], implicit-def early-clobber $q3, $4:[clobber], implicit-def early-clobber $q4, $5:[clobber], implicit-def early-clobber $q5, $6:[clobber], implicit-def early-clobber $q6, $7:[clobber], implicit-def early-clobber $q7
  %2:gpr, %3:gpr = VMOVRRD %1:dpr, 14, $noreg
  %5:spr = COPY %1.ssub_0:dpr
  $s0 = COPY %5:spr
  BX_RET 14, $noreg, implicit $s0

# End machine code for function shouldRewriteCopySrc.

*** Bad machine code: Invalid register class for subregister index ***
- function:    shouldRewriteCopySrc
- basic block: %bb.0 bb (0x9947838)
- instruction: %5:spr = COPY %1.ssub_0:dpr
- operand 1:   %1.ssub_0:dpr
Register class DPR does not fully support subreg index ssub_0
LLVM ERROR: Found 1 machine code errors.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/llc -mtriple=arm-none-eabihf -mcpu=cortex-a55
1.	Running pass 'Function Pass Manager' on module '<stdin>'.
2.	Running pass 'Verify generated machine code' on function '@shouldRewriteCopySrc'
 #0 0x0000000003904db7 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/llc+0x3904db7)
 #1 0x000000000390286e llvm::sys::RunSignalHandlers() (/b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/llc+0x390286e)
 #2 0x000000000390546a SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
 #3 0x00007fa85b978140 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x13140)
 #4 0x00007fa85b48cd61 raise (/lib/x86_64-linux-gnu/libc.so.6+0x38d61)
 #5 0x00007fa85b476537 abort (/lib/x86_64-linux-gnu/libc.so.6+0x22537)
 #6 0x000000000386e8ca llvm::report_fatal_error(llvm::Twine const&, bool) (/b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/llc+0x386e8ca)
 #7 0x0000000002ae05fd (/b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/llc+0x2ae05fd)
 #8 0x0000000002ae165b (anonymous namespace)::MachineVerifierLegacyPass::runOnMachineFunction(llvm::MachineFunction&) MachineVerifier.cpp:0:0
 #9 0x00000000029da923 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/llc+0x29da923)
#10 0x0000000002f48d23 llvm::FPPassManager::runOnFunction(llvm::Function&) (/b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/llc+0x2f48d23)
#11 0x0000000002f4f751 llvm::FPPassManager::runOnModule(llvm::Module&) (/b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/llc+0x2f4f751)
#12 0x0000000002f4942d llvm::legacy::PassManagerImpl::run(llvm::Module&) (/b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/llc+0x2f4942d)
...

@arsenm
Copy link
Contributor Author

arsenm commented May 5, 2025

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/18417

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

Register class DPR does not fully support subreg index ssub_0

Unrepresentable cases should have been filtered out by the default logic

arsenm added a commit that referenced this pull request May 5, 2025
This reverts commit 9d90f8b.

Test fails the machine verifier. There's a bug somewhere, the
unrepresentable cases should be avoided by the default logic.
IanWood1 pushed a commit to IanWood1/llvm-project that referenced this pull request May 6, 2025
IanWood1 pushed a commit to IanWood1/llvm-project that referenced this pull request May 6, 2025
IanWood1 pushed a commit to IanWood1/llvm-project that referenced this pull request May 6, 2025
GeorgeARM pushed a commit to GeorgeARM/llvm-project that referenced this pull request May 7, 2025
GeorgeARM pushed a commit to GeorgeARM/llvm-project that referenced this pull request May 7, 2025
All of the overrides of shouldRewriteCopySrc appear to be hacks
for bugs in the base implementation, so I'm trying to delete
all of the overrides. I was expecting this to find an example
issue like the x86 version, but no tests change with this.
GeorgeARM pushed a commit to GeorgeARM/llvm-project that referenced this pull request May 7, 2025
This reverts commit 9d90f8b.

Test fails the machine verifier. There's a bug somewhere, the
unrepresentable cases should be avoided by the default logic.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants