Capability.is_valid() treated as a constant by the compiler

[PhilDay-CT]

The followling

{
	size_t size=10;
	auto p1 = malloc(size);		
		
	Debug::log("p1: {} {}", p1, Capability{p1}.is_valid());
	free(p1);
	Debug::log("p1: {} {}", p1, Capability{p1}.is_valid());
}

gives

mem test: heap at start: 4096
mem test: p1: 0x80007b10 (v:1 0x80007b10-0x80007b20 l:0x10 o:0x0 p: G RWcgm- -- ---) true
mem test: p1: 0x80007b10 (v:0 0x80007b10-0x80007b20 l:0x10 o:0x0 p: G RWcgm- -- ---) true

[resistor]

I did some investigation on this issue, and it turns out to be somewhat tricky. Not because the specific symptom is hard to address, but because it exposes a gap in the compiler's modeling more broadly.

The fundamental problem is that LLVM is not modeling the valid bit at all, and therefore was completely unaware that a function call like free might change it. That can be bandaided by telling LLVM to pretend that reading the valid bit reads from memory, which will cause it to conservatively preserve the ordering of that read with respect to things like calls to free.

However, this causes knock-on effects because it turns out that we depend on valid bit reads not having side effects, to implement things like CToPtr when implementing CHERIv9 semantics. There's probably other intrinsics lurking around that depend on it as well.

[resistor]

Fix here, waiting for LLVM 17 to land: resistor@985057d