[NVPTX] Adjust data layout according to LLVM's change

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[NVPTX] Adjust data layout according to LLVM's change

Adam Cieszkiel via cfe-dev
Hello,

I'm curious, is it safe to change an alignment i128 type for NVPTX target? I made a patch to the LLVM backend and added `-i128:128` into data layout.

But after it became that LLVM and Clang layouts are different and error is thrown at Clang side:
> backend data layout 'e-i64:64-i128:128-v16:16-v32:32-n16:32:64' does not match expected target description 'e-i64:64-v16:16-v32:32-n16:32:64'

Could you please help with advice, can I just make another patch for Clang to modify the layout? Won't it break any backward compatibility?

Thanks a lot,
Denys Zariaiev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [NVPTX] Adjust data layout according to LLVM's change

Adam Cieszkiel via cfe-dev


On 07/11/2017 03:21 PM, Denys Zariaiev via cfe-dev wrote:
Hello,

I'm curious, is it safe to change an alignment i128 type for NVPTX target? I made a patch to the LLVM backend and added `-i128:128` into data layout.

But after it became that LLVM and Clang layouts are different and error is thrown at Clang side:
> backend data layout 'e-i64:64-i128:128-v16:16-v32:32-n16:32:64' does not match expected target description 'e-i64:64-v16:16-v32:32-n16:32:64'

Could you please help with advice, can I just make another patch for Clang to modify the layout? Won't it break any backward compatibility?

There could be some backward compatibility issues with linking new IR files with old IR files (because you're increasing the alignment requirements for i128), but often no more than other ISAs when new SIMD instructions are added, etc. For the NVPTX backend, this might be a concern if it affects anything in libdevice (the bitcode library that is shipped with CUDA in bitcode form), otherwise, I don't think it is a concern. In general, however, I think you should just update Clang.

 -Hal


Thanks a lot,
Denys Zariaiev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [NVPTX] Adjust data layout according to LLVM's change

Adam Cieszkiel via cfe-dev
I didn't find any evidence that libdevice has anything related to i128's. And seems, in general, i128 numbers are not very popular in CUDA programming :)
Thanks for the advice!


On Wed, Jul 12, 2017 at 4:10 PM Hal Finkel <[hidden email]> wrote:


On 07/11/2017 03:21 PM, Denys Zariaiev via cfe-dev wrote:
Hello,

I'm curious, is it safe to change an alignment i128 type for NVPTX target? I made a patch to the LLVM backend and added `-i128:128` into data layout.

But after it became that LLVM and Clang layouts are different and error is thrown at Clang side:
> backend data layout 'e-i64:64-i128:128-v16:16-v32:32-n16:32:64' does not match expected target description 'e-i64:64-v16:16-v32:32-n16:32:64'

Could you please help with advice, can I just make another patch for Clang to modify the layout? Won't it break any backward compatibility?

There could be some backward compatibility issues with linking new IR files with old IR files (because you're increasing the alignment requirements for i128), but often no more than other ISAs when new SIMD instructions are added, etc. For the NVPTX backend, this might be a concern if it affects anything in libdevice (the bitcode library that is shipped with CUDA in bitcode form), otherwise, I don't think it is a concern. In general, however, I think you should just update Clang.

 -Hal


Thanks a lot,
Denys Zariaiev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Loading...