[TwoAddressInstruction] Check if segment was found when updating subreg LIs #65916
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…eg LIs This patch fixes a crash I was seeing when working with subregisters in a separate upcoming patch. Some of the RVV tests have -early-live-intervals enabled, which triggers this subregister liveness updating code in TwoAddressInstruction. The INSERT_SUBREG in the test case gets converted to a COPY, so it tries to update the subranges for %1 below: ********** INTERVALS ********** V8 [0B,16r:0) 0@0B-phi %0 [16r,32r:0) 0@16r weight:0.000000e+00 %1 [32r,48r:0) 0@32r L000000000000003C [32r,48r:0) 0@32r L00000000000003C0 [32r,32d:0) 0@32r weight:0.000000e+00 %2 EMPTY weight:0.000000e+00 %3 [48r,48d:0) 0@48r weight:0.000000e+00 0B bb.0: liveins: $v8 16B %0:vr = COPY $v8 32B undef %1.sub_vrm1_0:vrm8 = COPY %0:vr 48B dead %3:vrm4 = COPY %1.sub_vrm4_0:vrm8 64B PseudoRET The subrange for %1 L00000000000003C0 [32r,32d:0) doesn't overlap with sub_vrm1_0's lane mask, so it tries to merge 0@32r. It calls FindSegmentContaining(32B), 32B being the instruction index for the INSERT_SUBREG-turned-COPY. But 32B isn't actually in [32r,32d:0) so it returns end(). The code wasn't checking for end() though so it crashed when dereferencing DefSeg. I'm not familiar with this area in the slightest, but I presume we wanted to find the segment at 32r? And in this test case there's no other segment in the subrange anyway, so we need to check if DefSeg exists. I also did a quick check, nothing in llvm-check-codegen seems to trigger this code. Not sure if that will change if -early-live-intervals is enabled by default.
|
Hi @lukel97 I do some experiment which recompute the LiveInterval even it has subrange inside TwoAddressInstructionPass pass. Should they achieve the same result? |
|
@BeMg Thanks for running that, I think they should be the same. The only subrange in |
…it should always have another segment after it
lukel97
added a commit
to lukel97/llvm-project
that referenced
this pull request
Sep 21, 2023
Similar to llvm#65598, if we're using a vslideup to insert a fixed length vector into another vector, then we can work out the minimum number of registers it will need to slide up across given the minimum VLEN, and shrink the type operated on to reduce LMUL accordingly. This is somewhat dependent on llvm#65916, since it introduces a subregister copy that triggers a crash with -early-live-intervals in one of the tests.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch fixes a crash I was seeing when working with subregisters in a
separate upcoming patch. Some of the RVV tests have -early-live-intervals
enabled, which triggers this subregister liveness updating code in
TwoAddressInstruction.
The INSERT_SUBREG in the test case gets converted to a COPY, so it tries to
update the subranges for %1 below:
********** INTERVALS **********
V8 [0B,16r:0) 0@0B-phi
%0 [16r,32r:0) 0@16r weight:0.000000e+00
%1 [32r,48r:0) 0@32r L000000000000003C [32r,48r:0) 0@32r L00000000000003C0 [32r,32d:0) 0@32r weight:0.000000e+00
%2 EMPTY weight:0.000000e+00
%3 [48r,48d:0) 0@48r weight:0.000000e+00
0B bb.0:
liveins: $v8
16B %0:vr = COPY $v8
32B undef %1.sub_vrm1_0:vrm8 = COPY %0:vr
48B dead %3:vrm4 = COPY %1.sub_vrm4_0:vrm8
64B PseudoRET
The subrange for %1 L00000000000003C0 [32r,32d:0) doesn't overlap with
sub_vrm1_0's lane mask, so it tries to merge 0@32r. It calls
FindSegmentContaining(32B), 32B being the instruction index for the
INSERT_SUBREG-turned-COPY. But 32B isn't actually in [32r,32d:0) so it returns
end(). The code wasn't checking for end() though so it crashed when
dereferencing DefSeg.
I'm not familiar with this area, but my guess is that we need to handle the case where a subrange only has one segment, e.g. where there were no previous defs before the insert_subregister.
I also did a quick check, nothing in llvm-check-codegen seems to trigger this
code. Not sure if that will change if -early-live-intervals is enabled by
default.