[IRGen] Zero-init stack shadow copies of values at -Onone. #16486
Conversation
|
@swift-ci please test |
lib/IRGen/IRGenSIL.cpp
Outdated
| @@ -719,6 +719,28 @@ class IRGenSILFunction : | |||
| } | |||
| } | |||
|
|
|||
| // To make it unambiguous whether a `var` binding has been initialized, | |||
There was a problem hiding this comment.
///
Doesn't show up in Doxygen, but some editors format the comments nicer then.
lib/IRGen/IRGenSIL.cpp
Outdated
| // zero-initialize the first pointer-sized field. LLDB uses this to | ||
| // recognize to detect uninitizialized variables. This can be removed once | ||
| // swiftc switches to @llvm.dbg.addr() intrinsics. | ||
| void zeroInit(llvm::AllocaInst *AI) { |
There was a problem hiding this comment.
it looks like we could just make this an llvm::AllocaInst & ?
There was a problem hiding this comment.
No, the other user doesn't seem to always pass an alloca, so we can't just blatantly make the dyn_cast<> a cast<> [I tried]. If you think it's a bug, the assertion fires while building the swift standard library.
There was a problem hiding this comment.
I would like to know: what is it when it isn't an AllocaInst? Just wondering if there is another case we should handle.
|
The commit message is inaccurate, this is IRGen not SILGen. |
|
Build failed |
Thanks! I'll fix this. |
|
Looks like this change broke a bunch of lldb tests. I'm going to investigate :) |
|
We looked at this with Adrian and this patch is wrong. I'm going to submit an update. |
We already zero init AllocStack, and here's the same. The debugger's variable view shows up variables on the line where they're declared (before they've been initialized). In some cases, we just print garbage. In some others, it's dangerous (imagine an array which we believe has 2^32 elements because we ended up reusing a stack slot). This way it's always consistent, as lldb uses the first word to understand whether an object is initialized or not here. Fixes <rdar://problem/39883298>
dcci
changed the title
|
@swift-ci test |
|
Build failed |
|
Build failed |
| if (DL.getTypeSizeInBits(AI->getAllocatedType()) < | ||
| DL.getPointerSizeInBits()) | ||
| return; | ||
|
|
There was a problem hiding this comment.
// No debug location is how LLVM marks prologue instructions.
We already zero init AllocStack, and here's the same.
The debugger's variable view shows up variables on the line
where they're declared (before they've been initialized).
In some cases, we just print garbage. In some others, it's
dangerous (imagine an array which we believe has 2^32 elements
because we ended up reusing a stack slot). This way it's always
consistent, as lldb uses the first word to understand whether
an object is initialized or not here.
Fixes rdar://problem/39883298