Skip to content

Commit 7b1b0a0

Browse files
committed
Add comments to destroy_addr in SIL.rst.
`destroy_addr` is never semantically a "no-op". Just because an instruction can be safely eliminated does not mean the instruction has no semantics! That would be like saying we could move an unknown memory read below an otherwise dead store!
1 parent 10bf892 commit 7b1b0a0

File tree

1 file changed

+4
-3
lines changed

1 file changed

+4
-3
lines changed

docs/SIL.rst

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -2525,9 +2525,10 @@ except that ``destroy_addr`` may be used even if ``%0`` is of an
25252525
address-only type. This does not deallocate memory; it only destroys the
25262526
pointed-to value, leaving the memory uninitialized.
25272527

2528-
If ``T`` is a trivial type, then ``destroy_addr`` is a no-op. However, even a
2529-
memory location ``%a`` with a trivial type must not be accessed after a
2530-
``destroy_addr %a``.
2528+
If ``T`` is a trivial type, then ``destroy_addr`` can be safely
2529+
eliminated. However, a memory location ``%a`` must not be accessed
2530+
after ``destroy_addr %a`` (which has not yet been eliminated)
2531+
regardless of its type.
25312532

25322533
index_addr
25332534
``````````

0 commit comments

Comments
 (0)