LLVM unit tests

[JoelleJS]

#312

[vosen]

I don't see the Rust code to generate those tests. Not sure if I botched the explanation, your code is still in progress or you forgot to check it in or, but the tests are one part. The other part is Rust code: for each file there should be a rust unit test (generated by extending the existing macro that generates unit tests) to verify that .ll match LLVM bitcode generated by the compiler

[JoelleJS]

@vosen Yep, still working on that part. Just wanted the .ll files committed

[JoelleJS]

Okay, the tests seem to be working individually, e.g. cargo test -p ptx -- ::add_llvm. However, when running cargo test -p ptx -- llvm --nocapture I can see that it only runs a few tests and then fails with SIGSEGV or SIGABRT.

I'm thinking there is some kind of memory leak, but I haven't been able to find it. Perhaps your trained eyes see it quicker @vosen

[vosen]

I'm not at a computer right now, but I suspect LLVMParseBitcode2. Try LLVMParseBitcodeInContext2. LLVM C API has a bunch of those function which don't take an explicit context parameter and use some sort of default global context. That explodes when mixed with code that uses explicit context (like ZLUDA). It's a horrible default and I was bitten by it previously śr., 5 lut 2025, 16:32 użytkownik Joëlle van Essen ***@***.***> napisał:

…

Okay, the tests seem to be working individually, e.g. cargo test -p ptx -- ::add_llvm. However, when running cargo test -p ptx -- llvm --nocapture I can see that it only runs a few tests and then fails with SIGSEGV or SIGABRT. I'm thinking there is some kind of memory leak, but I haven't been able to find it. Perhaps your trained eyes see it quicker @vosen <https://github.com/vosen> — Reply to this email directly, view it on GitHub <#324 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJGQ2EKCKICFWFB32AILRL2OIVILAVCNFSM6AAAAABVHOKEYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMZXGI2TKMBWGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[JoelleJS]

@vosen That was exactly it, good catch.

All tests succeed, as expected (the .ll files were generated from the LLVM IR produced in the tests). The assumption is that the files are currently correct.

Currently, when the assertion fails it looks like this:

assertion `left == right` failed
  left: "declare i32 @__zluda_ptx_impl_sreg_tid(i8) #0\n\ndeclare i32 @__zluda_ptx_impl_sreg_ntid(i8) #0\n\ndeclare i32 @__zluda_ptx_impl_sreg_ctaid(i8) #0\n\ndeclare i32 @__zluda_ptx_impl_sreg_nctaid(i8) #0\n\ndeclare i32 @__zluda_ptx_impl_sreg_clock() #0\n\ndeclare i32 @__zluda_ptx_impl_sreg_lanemask_lt() #0\n\ndefine amdgpu_kernel void @neg(ptr addrspace(4) byref(i64) %\"34\", ptr addrspace(4) byref(i64) %\"35\") #0 {\n  %\"36\" = alloca i64, align 8, addrspace(5)\n  %\"37\" = alloca i64, align 8, addrspace(5)\n  %\"38\" = alloca i32, align 4, addrspace(5)\n  br label %1\n\n1:                                                ; preds = %0\n  %\"39\" = load i64, ptr addrspace(4) %\"34\", align 4\n  store i64 %\"39\", ptr addrspace(5) %\"36\", align 4\n  %\"40\" = load i64, ptr addrspace(4) %\"35\", align 4\n  store i64 %\"40\", ptr addrspace(5) %\"37\", align 4\n  %\"42\" = load i64, ptr addrspace(5) %\"36\", align 4\n  %\"47\" = inttoptr i64 %\"42\" to ptr\n  %\"41\" = load i32, ptr %\"47\", align 4\n  store i32 %\"41\", ptr addrspace(5) %\"38\", align 4\n  %\"44\" = load i32, ptr addrspace(5) %\"38\", align 4\n  %\"43\" = sub i32 0, %\"44\"\n  store i32 %\"43\", ptr addrspace(5) %\"38\", align 4\n  %\"45\" = load i64, ptr addrspace(5) %\"37\", align 4\n  %\"46\" = load i32, ptr addrspace(5) %\"38\", align 4\n  %\"48\" = inttoptr i64 %\"45\" to ptr\n  store i32 %\"46\", ptr %\"48\", align 4\n  ret void\n}\n\nattributes #0 = { \"amdgpu-unsafe-fp-atomics\"=\"true\" \"no-trapping-math\"=\"true\" \"uniform-work-group-size\"=\"true\" }"
 right: "declare i32 @__zluda_ptx_impl_sreg_tid(i8) #0\n\ndeclare i32 @__zluda_ptx_impl_sreg_ntid(i8) #0\n\ndeclare i32 @__zluda_ptx_impl_sreg_ctaid(i8) #0\n\ndeclare i32 @__zluda_ptx_impl_sreg_nctaid(i8) #\n\ndeclare i32 @__zluda_ptx_impl_sreg_clock() #0\n\ndeclare i32 @__zluda_ptx_impl_sreg_lanemask_lt() #0\n\ndefine amdgpu_kernel void @neg(ptr addrspace(4) byref(i64) %\"34\", ptr addrspace(4) byref(i64) %\"35\") #0 {\n  %\"36\" = alloca i64, align 8, addrspace(5)\n  %\"37\" = alloca i64, align 8, addrspace(5)\n  %\"38\" = alloca i32, align 4, addrspace(5)\n  br label %1\n\n1:                                                ; preds = %0\n  %\"39\" = load i64, ptr addrspace(4) %\"34\", align 4\n  store i64 %\"39\", ptr addrspace(5) %\"36\", align 4\n  %\"40\" = load i64, ptr addrspace(4) %\"35\", align 4\n  store i64 %\"40\", ptr addrspace(5) %\"37\", align 4\n  %\"42\" = load i64, ptr addrspace(5) %\"36\", align 4\n  %\"47\" = inttoptr i64 %\"42\" to ptr\n  %\"41\" = load i32, ptr %\"47\", align 4\n  store i32 %\"41\", ptr addrspace(5) %\"38\", align 4\n  %\"44\" = load i32, ptr addrspace(5) %\"38\", align 4\n  %\"43\" = sub i32 0, %\"44\"\n  store i32 %\"43\", ptr addrspace(5) %\"38\", align 4\n  %\"45\" = load i64, ptr addrspace(5) %\"37\", align 4\n  %\"46\" = load i32, ptr addrspace(5) %\"38\", align 4\n  %\"48\" = inttoptr i64 %\"45\" to ptr\n  store i32 %\"46\", ptr %\"48\", align 4\n  ret void\n}\n\nattributes #0 = { \"amdgpu-unsafe-fp-atomics\"=\"true\" \"no-trapping-math\"=\"true\" \"uniform-work-group-size\"=\"true\" }"

These can be copied and diffed of course, but I think it would be more convenient to use the pretty_assertions crate (link) to show a clear diff in the output itself. Do you agree?

[JoelleJS]

Marked this as ready but I just realized I forgot the following point:

If there's the a variable set (pick a name you like) that points to a directory then it also is written to the directory.

Will do that soon.