[NVPTX] Instruction selection failures for NVPTXISD::LoadV2 in presence of different source destination types

[nirvedhmeshram]

In this LLVM IR

define void @foo(ptr noalias readonly align 16 %0, ptr noalias readonly align 16 %1) {
%3 = getelementptr half, ptr %0, i64 0
%4 = load <8 x half>, ptr %3, align 16
%5 = fpext <8 x half> %4 to <8 x float>
store <8 x float> %5, ptr %1, align 16
ret void
}

!nvvm.annotations = !{!0}

!0 = !{ptr @foo, !"kernel", i32 1}

running with bin/llc < ~/test.ll -march=nvptx -mcpu=sm_80 --debug will get the following failure
https://gist.github.com/nirvedhmeshram/59912f126126f00a22920b770c330782

However, if you remove the nvvm.annotation this will work as it makes a LDV_f32_v2_ari, so my first question is, is it by design that we dont want to use this code for addrspace 1?
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/NVPTX/NVPTXISelDAGToDAG.cpp#L1071-L1085

because then its hitting this part
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/NVPTX/NVPTXISelDAGToDAG.cpp#L1599-L1622
which is not meant to handle the NVPTXISD::LoadV nodes so we can extend its handling if that is the right thing to do?

[nirvedhmeshram]

Hi @Artem-B , I see you actively contributing to the nvptx target, please let me know if you can help with this?

[Artem-B]

This is certainly unexpected.

On top of that there's something odd going on. The load gets split into: 4xf32, 2xf32, f16, f16, which is a rather odd arrangement.

  t41: f32,f32,f32,f32,ch = NVPTXISD::LoadV4<(load (s64) from %ir.4, align 16, addrspace 1)> t0, t10, undef:i32, Constant:i32<1>
    t68: i32 = add t10, Constant:i32<12>
  t72: f16,ch = load<(load (s16) from %ir.4 + 12, align 4, basealign 16, addrspace 1)> t0, t68, undef:i32
    t65: i32 = add t10, Constant:i32<14>
  t70: f16,ch = load<(load (s16) from %ir.4 + 14, basealign 16, addrspace 1)> t0, t65, undef:i32
    t21: i32 = add nuw t10, Constant:i32<8>
  t37: f32,f32,ch = NVPTXISD::LoadV2<(load (s32) from %ir.4 + 8, align 8, basealign 16, addrspace 1)> t0, t21, undef:i32, Constant:i32<1>

[nirvedhmeshram]

right, ideally we would want just two 4xf32 loads

[Artem-B]

Looks like tryLDGLDU needs to know whether the load we're doing is an extending load, but the op we're lowering is a target node which no longer has this info. Makes me wonder why we didn't run into this issue before.

Non-kernels work, because they operate on generic pointers, so we never get into tryLDGLDU.

I'm not sure yet what's the best way to address the problem.

However, if you remove the nvvm.annotation this will work as it makes a LDV_f32_v2_ari, so my first question is, is it by design that we dont want to use this code for addrspace 1?

To answer your question -- using ldg/ldu is an optimization which is only applicable for pointers in the global address space. We can infer it for the kernel pointer arguments, but not for regular functions.

[Artem-B]

https://reviews.llvm.org/D153477 should make things work.
Sub-optimal vector splitting + explicit conversion is still there, but the code should work and ptxas will probably generate similar SASS to what it generates for non-kernels.

[Artem-B]

Reproducer: https://godbolt.org/z/nzsd16MrP

[nirvedhmeshram]

Hi @Artem-B I was wondering if we will be able to land the patch soon, we have downstream applications blocked on it that we would like to cleanly support. Thanks.

[Artem-B]

The patch still needs to be reviewed. I'll land it once it's stamped.