[AMDGPU] No registers from class available to allocate for R600 / Cannot select for AMDGCN #58210
Comments
EugeneZelenko
added
backend:AMDGPU
crash
|
@llvm/issue-subscribers-backend-amdgpu |
|
Reproduced on r600 with unhandled address space error in debug mode, and on amdgcn with the Compiled successfully on X86. |
|
Following code compiles successfully, with SelectionDAG and GlobalISel: |
|
The issue is for r600 not amdgcn |
|
For the R600 case, I assume it's okay to return 128 for the vectorizing register bit width. That renders code with an infinite loop. Is there a reason why AMDGPUUnifyDivergentExitNodes is not scheduled for R600? |
Because it's barely (not really) maintained. Don't really follow the point about the infinite loop. The vector register bit width shouldn't matter for producing functioning code |
|
https://godbolt.org/z/3hjjfsThn The instruction |
poison doesn't mean "won't compile" and nothing is weird with that, that part should just work. The flat pointers aren't going to work on r600. Also, the alloca is the wrong address space. The only thing worth fixing here would be the " no registers from class available" if it manifests using address spaces that are supposed to work. With the address spaces fixed, this is broken for other reasons: Overall this is just demonstrating that r600 was never really completed and barely works. |
Sorry for jumping in. Short question, what means that statement for end-users especially in regard to OpenCL? Could this be interpreted as one of the reasons why clover had much more difficulties on TeraScale compared to GCN hardware? I think it can be said that at least in the past clover and (older) LLVM worked to some degree also on TeraScale hardware even if Perhaps it would make sense to mention the "r600 LLVM limitations and overall incompleteness" at a more official place like in the LLVM AMDGPU backend user guide. 🤔 And finally, it looks that r600 support in LLVM could be dropped at some point, - simply because there is no more practical use for it. Regarding OpenCL in Mesa there will exist also for TeraScale hardware rusticl as an alternative for "LLVM clover" even if it is somewhat slower than clover. Yeah, and before r600 will be purged please add your "AMDGPU/R600: Special case addrspacecast lowering for null" commit. I hoped it would land in LLVM 17. 😉 /cc Maybe something from here is of interest for @Triang3l |
|
I tried inserting the AMDGPUUnifyDivergentExitNodes pass to ensure there is an exit block in CFGs that don't already have one due to infinite loops. That does not suffice and that more work is required in the R600MachineCFGStructurizer. Is it worth the effort to fix this issue for an architecture that may hardly be used these days? |
|
@gandhi56 Yes, you are most likely right. As far I know the r600 LLVM backend is nowadays rarely used. I am aware regarding Linux only for Mesa clover and probably (partially) also the r600 Radeon Mesa driver. But perhaps some other AMD related stuff is still depending on it? I have no idea. Someone from AMD should bring here more clarity. And finally, a use of the r600 LLVM backend in the potential TeraScale Vulkan project "Terakan" is because of the above statement highly unlikely. So unlike to RADV Terakan will have almost sure only a NIR>SFN and no NIR>LLVM path. 🤔 |
Description
The following code crashes
llcwith "LLVM ERROR: no registers from class available" during "Greedy Register Allocator" pass for release build and "unhandled address space" during "GPU Load and Store Vectorizer" for debug build when targeting R600.The code also crashes
llcwith "LLVM ERROR: Cannot select: t13: ch = store<(store (s8) intoi1* poison), trunc to i8> t0, t15, undef:i64, undef:i64" when targeting AMDGCN, but compiles successfully for other architectures.Reproduction
https://godbolt.org/z/5rv3f6r8r
Code
Stack Trace
Release Build targeting R600
Debug Build targeting R600
Debug Build targeting AMDGCN
The text was updated successfully, but these errors were encountered: