AMDGPU fails to fold out useless half of 64-bit or

[arsenm]

In some tests I see this pattern appear:

        t334: v2i32 = BUILD_VECTOR Constant:i32<0>, t258
      t335: i64 = bitcast t334
    t188: i64 = or # D:1 t342, t335

We should be able to do a 32-bit or and drop the operation on the 0 bits. The same applies for other identity value elements, like -1 with and. This is similar to 09583de, except it's a variable case (and for or, instead of add/sub)

[llvmbot]

@llvm/issue-subscribers-backend-amdgpu

Author: Matt Arsenault (arsenm)

In some tests I see this pattern appear:

        t334: v2i32 = BUILD_VECTOR Constant:i32<0>, t258
      t335: i64 = bitcast t334
    t188: i64 = or # D:1 t342, t335

We should be able to do a 32-bit or and drop the operation on the 0 bits. The same applies for other identity value elements, like -1 with and. This is similar to 09583de, except it's a variable case (and for or, instead of add/sub)

[arsenm]

This particular instance appears to be a consequence of lowering large bit shifts on buffer descriptors:

  %out.load = load i160, ptr addrspace(4) %out.kernarg.offset, align 4, !invariant.load !0
  %2 = lshr i160 %out.load, 32
  %3 = trunc i160 %2 to i128

Eventually this turns into 64-bit shifts used to implement the wide shift, then we optimize the 64-bit by 32 to a pair of 0 and 32-bit shift

[arsenm]

@krzysz00 we might want to change this 160-bit extract pattern in the buffer lowering. While the shift is the middle end canonical way to extract relevant bits, it's just giving the backend extra steps on the way to turning this into <4 x i32> or <5 x i32>

[krzysz00]

@arsenm I take it you want it as bitcast i160 to <5 x i32> and then some shufflevector and extractelement?

Do you want to patch it or should I?

[arsenm]

@arsenm I take it you want it as bitcast i160 to <5 x i32> and then some shufflevector and extractelement?

Yes, shufflevector for a subvector extract and extractelement fro a single one

Do you want to patch it or should I?

Would be good if you could do it, my backlog grows by the hour. This also doesn't fix all the unfolded 0s I've encountered, just some of them

[arsenm]

Example buffer case:

define amdgpu_kernel void @buffer_last_use_load_0(ptr addrspace(7) inreg %in, ptr addrspace(7) inreg %out) {
entry:
  %val = load i32, ptr addrspace(7) %in, align 4, !amdgpu.last.use !0
  store i32 %val, ptr addrspace(7) %out, align 4
  ret void
}

!0 = !{}

Before codegen this expands to:

define amdgpu_kernel void @buffer_last_use_load_0({ ptr addrspace(8), i32 } inreg %in, { ptr addrspace(8), i32 } inreg %out) #0 {
entry:
  %buffer_last_use_load_0.kernarg.segment = call nonnull align 32 dereferenceable(320) ptr addrspace(4) @llvm.amdgcn.kernarg.segment.ptr()
  %in.kernarg.offset1 = bitcast ptr addrspace(4) %buffer_last_use_load_0.kernarg.segment to ptr addrspace(4)
  %in.load = load i160, ptr addrspace(4) %in.kernarg.offset1, align 16, !invariant.load !0
  %0 = lshr i160 %in.load, 32
  %1 = trunc i160 %0 to i128
  %in.load.ptr.rsrc = inttoptr i128 %1 to ptr addrspace(8)
  %in.load.ptr.off = trunc i160 %in.load to i32
  %out.kernarg.offset = getelementptr inbounds i8, ptr addrspace(4) %buffer_last_use_load_0.kernarg.segment, i64 32
  %out.load = load i160, ptr addrspace(4) %out.kernarg.offset, align 16, !invariant.load !0
  %2 = lshr i160 %out.load, 32
  %3 = trunc i160 %2 to i128
  %out.load.ptr.rsrc = inttoptr i128 %3 to ptr addrspace(8)
  %out.load.ptr.off = trunc i160 %out.load to i32
  %val = call i32 @llvm.amdgcn.raw.ptr.buffer.load.i32(ptr addrspace(8) align 4 %in.load.ptr.rsrc, i32 %in.load.ptr.off, i32 0, i32 0), !amdgpu.last.use !0
  call void @llvm.amdgcn.raw.ptr.buffer.store.i32(i32 %val, ptr addrspace(8) align 4 %out.load.ptr.rsrc, i32 %out.load.ptr.off, i32 0, i32 0)
  ret void
}

[krzysz00]

Since ptr addrspace(7) is unlikely to appear directly as an argument any time soon - I think - I'll get around to this Eventually (tm)

[krzysz00]

(proof of life because I'm going through my tabs: at the rate this is going, I'll need a whole second Eventually to have time to try and fix this, especially since I think it'd be a workaround anyway)