diff options
author | Luigi Sartor Piucco <luigipiucco@gmail.com> | 2025-05-22 10:12:34 -0300 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-05-22 15:12:34 +0200 |
commit | 83de1efae389707f7fd03bf3ed2e42934122b4fb (patch) | |
tree | afafc2fb7d228d47eb12f6cb0e9508593098c4f7 /llvm/lib/CodeGen/MachineBasicBlock.cpp | |
parent | 229aa6627a63012ac5e0b3587c87e94c2b5ad36f (diff) | |
download | llvm-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