-
Notifications
You must be signed in to change notification settings - Fork 13.4k
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
Conversation
@llvm/pr-subscribers-backend-arm Author: Matt Arsenault (arsenm) ChangesAll of the overrides of shouldRewriteCopySrc appear to be hacks Full diff: https://github.com/llvm/llvm-project/pull/125219.diff 2 Files Affected:
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); }
};
|
X86 version in #125224 |
There was a problem hiding this 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?
#125224, but the ARM change doesn't depend on that |
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. |
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.
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.
Then that needs to be reflected in a testcase. If code can be deleted and no test change, it should be deleted |
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. |
c058c3e
to
0096a5d
Compare
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. |
There was a problem hiding this 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
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.
0096a5d
to
96884a6
Compare
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 |
LLVM Buildbot has detected a new failure on builder 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
|
LLVM Buildbot has detected a new failure on builder 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
|
Unrepresentable cases should have been filtered out by the default logic |
This reverts commit 9d90f8b. Test fails the machine verifier. There's a bug somewhere, the unrepresentable cases should be avoided by the default logic.
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.
This reverts commit 9d90f8b. Test fails the machine verifier. There's a bug somewhere, the unrepresentable cases should be avoided by the default logic.
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.