Non-native endianness support in Clang

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

Non-native endianness support in Clang

Kristóf Umann via cfe-dev
Hello,
I'd like to implement the gnu attribute "scalar_storage_order" to mark structs with non-native endianness. My rational is working on network protocols over little endian architecture (for instance: RiscV).

An old bug is open on this issue here:
https://bugs.llvm.org/show_bug.cgi?id=35293

I'd like to discuss the possible ways to implement this.

The GCC implementation is pretty complicated, touching almost everything, modifying optimizations, etc...:
https://github.com/gcc-mirror/gcc/commit/292237f3c109f2e0d2752ad1e73181689f7d0d53

I think, it would be better, to implement this attribute in the frontend only, adding the required byte-swaps early.

Any thoughts, ideas, objections?

Thanks
          Guy Benyei
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Non-native endianness support in Clang

Kristóf Umann via cfe-dev

On 8/26/19 9:18 AM, Guy Benyei via llvm-dev wrote:

> Hello,
> I'd like to implement the gnu attribute "scalar_storage_order" to mark structs with non-native endianness. My rational is working on network protocols over little endian architecture (for instance: RiscV).
>
> An old bug is open on this issue here:
> https://bugs.llvm.org/show_bug.cgi?id=35293
>
> I'd like to discuss the possible ways to implement this.
>
> The GCC implementation is pretty complicated, touching almost everything, modifying optimizations, etc...:
> https://github.com/gcc-mirror/gcc/commit/292237f3c109f2e0d2752ad1e73181689f7d0d53
>
> I think, it would be better, to implement this attribute in the frontend only, adding the required byte-swaps early.


I agree. Adding the swaps in the frontend seems relatively
straightforward. As I understand it, for non-packed structs, you also
need to adjust the relative position of the padding?

  -Hal


>
> Any thoughts, ideas, objections?
>
> Thanks
>            Guy Benyei
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

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

Re: [llvm-dev] Non-native endianness support in Clang

Kristóf Umann via cfe-dev
AFAIK, the padding of non-packed structs shouldn't be affected, but bitfield offsets must be adjusted.
I'll test the solution thoroughly to make sure different structs with this attribute are interpreted the same on BE and LE targets.

Thanks
        Guy Benyei

-----Original Message-----
From: Finkel, Hal J. <[hidden email]>
Sent: Monday, August 26, 2019 9:59 PM
To: Guy Benyei <[hidden email]>; [hidden email]; [hidden email]
Subject: Re: [llvm-dev] Non-native endianness support in Clang


On 8/26/19 9:18 AM, Guy Benyei via llvm-dev wrote:

> Hello,
> I'd like to implement the gnu attribute "scalar_storage_order" to mark structs with non-native endianness. My rational is working on network protocols over little endian architecture (for instance: RiscV).
>
> An old bug is open on this issue here:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs
> .llvm.org%2Fshow_bug.cgi%3Fid%3D35293&amp;data=02%7C01%7Cguybe%40mella
> nox.com%7C5eb16d1a2f174a2b002808d72a57811a%7Ca652971c7d2e4d9ba6a4d1492
> 56f461b%7C0%7C0%7C637024427646321756&amp;sdata=Je2g85mVic2aq5H9gySsbsQ
> 8B6Kt0I03LWThuqDmjWQ%3D&amp;reserved=0
>
> I'd like to discuss the possible ways to implement this.
>
> The GCC implementation is pretty complicated, touching almost everything, modifying optimizations, etc...:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fgcc-mirror%2Fgcc%2Fcommit%2F292237f3c109f2e0d2752ad1e73181689
> f7d0d53&amp;data=02%7C01%7Cguybe%40mellanox.com%7C5eb16d1a2f174a2b0028
> 08d72a57811a%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637024427646
> 321756&amp;sdata=e2U1YX0Qnzl4AM1SNYIWIrJuQPi6JQmLBp%2FfbeJOxD8%3D&amp;
> reserved=0
>
> I think, it would be better, to implement this attribute in the frontend only, adding the required byte-swaps early.


I agree. Adding the swaps in the frontend seems relatively straightforward. As I understand it, for non-packed structs, you also need to adjust the relative position of the padding?

  -Hal


>
> Any thoughts, ideas, objections?
>
> Thanks
>            Guy Benyei
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev&amp;data=02%7C01%
> 7Cguybe%40mellanox.com%7C5eb16d1a2f174a2b002808d72a57811a%7Ca652971c7d
> 2e4d9ba6a4d149256f461b%7C0%7C0%7C637024427646321756&amp;sdata=gk%2Fnh7
> laaSGjUxAXMixQ76jtTiRxJehLlG3b%2F7fLDOY%3D&amp;reserved=0

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

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