aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/MachineBasicBlock.cpp
diff options
context:
space:
mode:
authorLuigi Sartor Piucco <luigipiucco@gmail.com>2025-05-22 10:12:34 -0300
committerGitHub <noreply@github.com>2025-05-22 15:12:34 +0200
commit83de1efae389707f7fd03bf3ed2e42934122b4fb (patch)
treeafafc2fb7d228d47eb12f6cb0e9508593098c4f7 /llvm/lib/CodeGen/MachineBasicBlock.cpp
parent229aa6627a63012ac5e0b3587c87e94c2b5ad36f (diff)
downloadllvm-83de1efae389707f7fd03bf3ed2e42934122b4fb.zip
llvm-83de1efae389707f7fd03bf3ed2e42934122b4fb.tar.gz
llvm-83de1efae389707f7fd03bf3ed2e42934122b4fb.tar.bz2
[LangRef] Comment on validity of volatile ops on null (#139803)
Some hardware (for example, certain AVR chips) have peripheral registers mapped to the data space address 0. Although a volatile load/store on `ptr null` already generates expected code, the wording in the LangRef makes operations on null seem like undefined behavior in all cases. This commit adds a comment that, for volatile operations, it may be defined behavior to access the address null, if the architecture permits it. The intended use case is MMIO registers with hard-coded addresses that include bit-value 0. A simple CodeGen test is included for AVR, as an architecture known to have this quirk, that does `load volatile` and `store volatile` to `ptr null`, expecting to generate `lds <reg>, 0` and `sts 0, <reg>`. See [this thread](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Adding.20the.20possibility.20of.20volatile.20access.20to.20address.200) and [the RFC](https://discourse.llvm.org/t/rfc-volatile-access-to-non-dereferenceable-memory-may-be-well-defined/86303) for discussion and context.
Diffstat (limited to 'llvm/lib/CodeGen/MachineBasicBlock.cpp')
0 files changed, 0 insertions, 0 deletions