CodeGen: add a missing check for bit-slice overlap in CV #7880
Conversation
Type dereferenced fragments are specified by offset and length in bits. The representation in CodeView is defined in terms of byte offsets. If the bit slice overlaps at a byte that is included, we would create invalid definition ranges. Consider the following scenario: ~~~ 01234567 01234567 ---------+--------- ==== ====== ~~~ Here bits 1-4 are marked as defined as well as bits 7-9. The byte range for the second portion overlaps and so we would say that bytes 1 and 2 are valid though there is potentially a hole. There is no way to represent this in the defined range for the local variable in CodeView. We simply can drop the fragment definition in such a scenario with the variables are "optimized out". Thanks to @rnk and @hjyamauchi for the discussion around this.
|
@swift-ci please test |
|
|
||
| declare void @llvm.dbg.value(metadata %0, metadata %1, metadata %2) #0 | ||
|
|
||
| attributes #0 = { nocallback nofree nosync nounwind speculatable willreturn memory(none) } |
There was a problem hiding this comment.
I am getting consistent failures in this branch because memory(none) is not supported in 5.10. The memory(…) attributes introduced in https://reviews.llvm.org/D135780 which are not part of the release/5.10 branch. You might be able to rewrite the test without memory(none) and get the same result. See #7484 for a similar problem that was solved removing the memory(…) attributes.
There was a problem hiding this comment.
Thanks for the heads up @drodriguez! I wonder why the CI didn't catch that. I'll put up a PR to drop the attribute.
There was a problem hiding this comment.
I think one needs to be explicit with "please test llvm" even in the LLVM repo. But it has not been successful for a while, so… (see https://ci.swift.org/job/pr-apple-llvm-project-llvm-macos/ and https://ci.swift.org/job/pr-apple-llvm-project-llvm-linux/)
Type dereferenced fragments are specified by offset and length in bits. The representation in CodeView is defined in terms of byte offsets. If the bit slice overlaps at a byte that is included, we would create invalid definition ranges.
Consider the following scenario:
Here bits 1-4 are marked as defined as well as bits 7-9. The byte range for the second portion overlaps and so we would say that bytes 1 and 2 are valid though there is potentially a hole. There is no way to represent this in the defined range for the local variable in CodeView. We simply can drop the fragment definition in such a scenario with the variables are "optimized out".
Thanks to @rnk and @hjyamauchi for the discussion around this.