Allow noinline functions to be called with correct argument types.

[etiotto]

This PR is currently blocked by:

#3974
#3612

[whitneywhtsang]

Can we resolve the problem in rewrite_stack_ptr pass introduced in #3497 instead of common pass?

[etiotto]

Can we resolve the problem in rewrite_stack_ptr pass introduced in #3497 instead of common pass?

I tried the new pass and found that it doen't help in this case. Consider this simple test case:

module attributes {triton_intel_gpu.target_arch = "spir64", "ttg.num-warps" = 4 : i32, ttg.shared = 0 : i32} {  
  tt.func public @kernel(%arg0: !tt.ptr<f32>, %extra: i32) {
    tt.call @noinline_simple_fn(%arg0) : (!tt.ptr<f32>) -> ()
    tt.return
  }
  tt.func private @noinline_simple_fn(%arg0: !tt.ptr<f32>) attributes {noinline = true} {
    tt.return
  }  
}

Here, if the extra kernel argument is dropped, then compilation succeeds and that pass works. However just adding the extra parameter to the kernel (or a parameter that is not a tt.ptr) causes the simple test to fail compilation.

Essentially, when the last parameter of the kernel is not a tt.ptr, lowering the code to the LLVM dialect (convert-triton-intel-gpu-to-llvm) fails, and the tritonintelgpu-rewrite-stack-ptr pass doesn't get a chance to be invoked. To fix the problem is therefore not sufficient adding tritonintelgpu-rewrite-stack-ptr to our pass pipeline, we need to fix the code while it is being lowered to the LLVM dialect.

[etiotto]

Can we resolve the problem in rewrite_stack_ptr pass introduced in #3497 instead of common pass?

I tried the new pass and found that it doen't help in this case. Consider this simple test case:

module attributes {triton_intel_gpu.target_arch = "spir64", "ttg.num-warps" = 4 : i32, ttg.shared = 0 : i32} {  
  tt.func public @kernel(%arg0: !tt.ptr<f32>, %extra: i32) {
    tt.call @noinline_simple_fn(%arg0) : (!tt.ptr<f32>) -> ()
    tt.return
  }
  tt.func private @noinline_simple_fn(%arg0: !tt.ptr<f32>) attributes {noinline = true} {
    tt.return
  }  
}

Here, if the extra kernel argument is dropped, then compilation succeeds and that pass works. However just adding the extra parameter to the kernel (or a parameter that is not a tt.ptr) causes the simple test to fail compilation.

Essentially, when the last parameter of the kernel is not a tt.ptr, lowering the code to the LLVM dialect (convert-triton-intel-gpu-to-llvm) fails, and the tritonintelgpu-rewrite-stack-ptr pass doesn't get a chance to be invoked. To fix the problem is therefore not sufficient adding tritonintelgpu-rewrite-stack-ptr to our pass pipeline, we need to fix the code while it is being lowered to the LLVM dialect.

I have made a copy of CallOpConversion so that we can put a fix in it instead of fixing common code.

[chengjunlu]

Is this our backend issue for converting the calling conversion? Why do we duplicate the %arg2 as the last param to the callee? It seems the callee doesn't require any global scratch space.

[ESI-SYD]

We reuse CallOpConversion from upstream one after the pass. promoteOperands will append GlobalScratchPtr.

intel-xpu-backend-for-triton/lib/Conversion/TritonGPUToLLVM/ControlFlowOpToLLVM.cpp

Lines 103 to 104 in fa4cfa0

	promotedOperands.push_back(LLVM::getGlobalScratchPtr(
	loc, rewriter, targetInfo, caller, opOffsetVal));

%arg2 added as lastArg.

intel-xpu-backend-for-triton/include/triton/Conversion/TritonGPUToLLVM/Utility.h

Lines 518 to 520 in fa4cfa0

	auto gmemBase = funcOp.getArgument(funcOp.getNumArguments() - 1);
	if (!allocOffset) {
	return gmemBase;

[chengjunlu]

The lowering pattern should transform the kernel entry function's signature as well. Rigth?
The global scratch space base address should be appended to the kernel entry's function.
The triton::CallOp lowering pattern should use the global scratch bases instead of reusing the user buffer which is passed as last argument, %arg2 in this case.

[etiotto]

Is this our backend issue for converting the calling conversion? Why do we duplicate the %arg2 as the last param to the callee? It seems the callee doesn't require any global scratch space.

No it is not related to the calling convention. We fix the calling convention in another transformation pattern (FixCallCConv).

[etiotto]

The lowering pattern should transform the kernel entry function's signature as well. Rigth? The global scratch space base address should be appended to the kernel entry's function. The triton::CallOp lowering pattern should use the global scratch bases instead of reusing the user buffer which is passed as last argument, %arg2 in this case.

I do not know what transformation patter is supposed to change the kernel signature. The host would have to pass a pointer to the global scratch place as well. @ESI-SYD do you know what part of the code is supposed to append the pointer to the scratch space to the kernel ?

[chengjunlu]

Let's use these two issue to track the problem here. Not to block this PR.
#3974
#3612

[etiotto]

I am putting this PR back into draft mode because the Triton FE/driver doesn't yet pass to the kernel a pointer to the global scratch space.

[chengjunlu]

No, the global scratch space is not supported by Intel GPU yet. The #3612