Fix compile time regression for null ptr comparisons

[gbaraldi]

Fixes the compile time regression in #59134 (does not address the performance regression that should be tracked and bisected)

[vtjnash]

Shouldn't this be an assert? It appears we only call this when the frontend IR put a check here mandating that the bit pattern be all zeros.

[gbaraldi]

There's a case which I haven't tracked down too well here but that we emit a null check on an alloca. Where we as frontend will comply with AMDGPU and emit the alloca on the correct addresspace

[gbaraldi]

JuliaGPU/AMDGPU.jl#780 i.e here. I think LLVM can and does fold those away for normal pointers but not here

[gbaraldi]

For code that emits those null checks see

function foo(C, A, ta)
       @inbounds for i in eachindex(C)
         x = ta == 0 ? A[1] : (ta == 1 ? A[1] : A[1])
         C[i] = x
         end
         nothing
         end
@code_llvm optimize=false foo(zeros(ComplexF64,1,1), ones(ComplexF64, 1), 1)

There are at least 3 null checks of allocas here

[vtjnash]

Ah okay right, we use that for emit_isa_and_defined in phi nodes, since it is a simple way to check a lot of possible things, since we cannot know (until runtime) whether that is a pointer to a heap object or alloca or sometimes both or something else. I still think upstream AMD is at fault here, since the C standard explicitly says that that the null pointer definition in any address space can have any bit pattern (e.g. -1) but is guaranteed not to point to a valid object:
https://www.gnu.org/software/libc//manual/html_node/Null-Pointer-Constant.html. It is very awkward then that AMD decided to use the same term to mean the opposite in LLVM: that the null pointer is guaranteed to have bit pattern 0 but might point at a valid object.

[gbaraldi]

The issue is LLVM hard codes null to 0, which is not what C says. And AMD is the only target that actually exposes that. The actual null is never a valid address, which is why in C amdgpu clang will introduce the same thing we're doing here.