83de1efae3
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.
16 lines
345 B
LLVM
16 lines
345 B
LLVM
; RUN: llc < %s -mtriple=avr | FileCheck %s
|
|
|
|
define i8 @load_volatile_null() {
|
|
; CHECK-LABEL: load_volatile_null:
|
|
; CHECK: lds r24, 0
|
|
%result = load volatile i8, ptr null
|
|
ret i8 %result
|
|
}
|
|
|
|
define void @store_volatile_null(i8 %a) {
|
|
; CHECK-LABEL: store_volatile_null:
|
|
; CHECK: sts 0, r24
|
|
store volatile i8 %a, ptr null
|
|
ret void
|
|
}
|