Use getPointerAddressSpace instead of cast<PointerType>.getAddressSpace.

[maleadt]

The former also handles vectors of pointers, which can occur after vectorization:

#5  0x00007f5bfe94de5e in llvm::cast<llvm::PointerType, llvm::Type> (Val=<optimized out>) at llvm/Support/Casting.h:578
578	  assert(isa<To>(Val) && "cast<Ty>() argument of incompatible type!");

(rr) up
#6  GCInvariantVerifier::visitAddrSpaceCastInst (this=this@entry=0x7ffd022fbf56, I=...) at julia/src/llvm-gc-invariant-verifier.cpp:66
66	    unsigned ToAS = cast<PointerType>(I.getDestTy())->getAddressSpace();

(rr) call I.dump()
%23 = addrspacecast <4 x ptr addrspace(10)> %wide.load to <4 x ptr addrspace(11)>, !dbg !43

Fixes aborts seen in #53070; cc @gbaraldi

[giordano]

Thanks for looking into this! Is there any simple test we can add to catch similar issue early, without having to run nanosoldier?

[maleadt]

Sure. I can add a lit test.

[vchuravy]

Any guard that is Ty->isPointerType probably needs to be changed to isPtrOrPtrVectorTy otherwise some of these changes will ignore PtrVector

[maleadt]

Any guard that is Ty->isPointerType probably needs to be changed to isPtrOrPtrVectorTy otherwise some of these changes will ignore PtrVector

I don't think all of them need to be changed. Yes, in the GC invariant verifier (and I'll push that shortly), but most of the code in codegen/cgutils doesn't actually know how to handle vectors of pointers, or expects to encounter them pre-optimization anyway. The change to getPointerAddressSpace probably isn't very useful in there, but I don't think it can hurt either (since subsequent cast<PointerType>s are expected to abort anyway).