[all-commits] [llvm/llvm-project] 83de1e: [LangRef] Comment on validity of volatile ops on n...

[Luigi Sartor Piucco via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 83de1efae389707f7fd03bf3ed2e42934122b4fb
      https://github.com/llvm/llvm-project/commit/83de1efae389707f7fd03bf3ed2e42934122b4fb
  Author: Luigi Sartor Piucco <luigipiucco at gmail.com>
  Date:   2025-05-22 (Thu, 22 May 2025)

  Changed paths:
    M llvm/docs/LangRef.rst
    A llvm/test/CodeGen/AVR/volatile-null.ll

  Log Message:
  -----------
  [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.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications