ICE when compiling simple swap<T> function

[ktf]

The following:

template <typename T>
inline void myswap(T& a, T& b)
{
  auto tmp = a;
  a = b;
  b = tmp;
}

void foo() {
  int *foo1 = nullptr;
  int *foo2 = nullptr;
  myswap(foo1, foo2);
}

results in a segmentation fault in:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
  * frame #0: 0x00000001000d4918 clspv`clspv::InferType(llvm::Value*, llvm::LLVMContext&, llvm::DenseMap<llvm::Value*, llvm::Type*, llvm::DenseMapInfo<llvm::Value*, void>, llvm::detail::DenseMapPair<llvm::Value*, llvm::Type*>>*) + 2068
    frame #1: 0x000000010001183c clspv`BitcastUtils::IsImplicitCasts(llvm::Module&, llvm::DenseMap<llvm::Value*, llvm::Type*, llvm::DenseMapInfo<llvm::Value*, void>, llvm::detail::DenseMapPair<llvm::Value*, llvm::Type*>>&, llvm::Instruction&, llvm::Value*&, llvm::Type*&, llvm::Type*&, bool, bool) + 332
    frame #2: 0x00000001000cb010 clspv`clspv::SimplifyPointerBitcastPass::runOnImplicitGEP(llvm::Module&) const + 400
    frame #3: 0x00000001000ca904 clspv`clspv::SimplifyPointerBitcastPass::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) + 152
    frame #4: 0x0000000102d88c90 clspv`llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) + 412
    frame #5: 0x00000001000e3d60 clspv`(anonymous namespace)::CompileModule(llvm::StringRef const&, std::__1::unique_ptr<llvm::Module, std::__1::default_delete<llvm::Module>>&, std::__1::vector<unsigned int, std::__1::allocator<unsigned int>>*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*) + 4948
    frame #6: 0x00000001000de120 clspv`clspv::Compile(int, char const* const*) + 2156
    frame #7: 0x000000018a82eb98 dyld`start + 6076

when compiled with:

clspv reproducer-swap.cl -cl-std=CLC++2021 -inline-entry-points -w -o foo.spirv

[ktf]

Any idea about this? Is there anything missing to reproduce? I can produce a segfault with this also in godbolt. Should I expect any help / followup or am I on my own?

[alan-baker]

This is tricky for clspv unfortunately. There's nothing help figure out how to interpret the type. So we don't know how to generate the code (though it fails before the SPIR-V generation). This is likely solvable once we start using the untyped pointers extension, but probably not worth it before then.

[ktf]

Ok, thank you. Do you have any estimate for that?

[alan-baker]

Not at the moment unfortunately.

[alan-baker]

I think I was wrong about untyped pointers solving this issue. Because the pointers are in the private address space, clspv can't actually utilize untyped pointers.