Quantcast

[RFC] Implement code generation for __unaligned

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

[RFC] Implement code generation for __unaligned

Ammarguellat, Zahira via cfe-dev
Dear all,

this is a proposal to improve the usefulness of clang in the context of systems
programming and embedded systems.

Our goal is to complete the code generation support of the existing __unaligned
support, which is implemented in clang as a Microsoft extension[1] under
-fms-extensions.

We have implemented most of the proposal but we'd want to gather feedback from
the community so we can contribute an implementation that successfully fits the
existing project goals.

1. Context
----------

In low-level programming it is not unusual that objects are in addresses not
aligned to the natural alignment of the data. In some architectures this is
only a performance issue, where unaligned accesses to objects are correct and
may only have to pay a penalty. But in other architectures this is a
correctness issue as these objects must be accessed using special unaligned
instructions. Failing to do so leads to a fault of the program.

Unfortunately the existing support of unaligned data is not very good in
existing C and C++ implementations. clang and gcc, support the aligned(x)
attribute, which can be used to increase or decrease (except for structs) the
alignment of the declared object. This means that it is not possible to have a
pointer to unaligned data easily.

(Examples assume common 32-bit architectures)

__attribute__((aligned(1))) int *p; // p is aligned(1) but *p is aligned(4)

The implementation of the __unaligned Microsoft extension[2] extended the type
system adding a new "unaligned" type-qualifier but no codegen was implemented
at that time. The goal was mostly parsing the Windows headers.

This proposal suggests to implement the missing parts of it, so it becomes
useful for architectures where unaligned accesses pose a correctness issue.

__unaligned int *p1; // p1 is aligned(4) *p1 is aligned(1)
int * __unaligned p2; // p2 is aligned(1), *p2 is aligned(4)
__unaligned int *__unaligned p3; // p3 is aligned(1), *p3 is aligned(1)
__unaligned int a[N]; // a[e] is aligned(1)

2. Proposal
-----------

Our proposal is basically implement the missing CodeGen bits for __unaligned.

Currently clang's codegen is oblivious to the unaligned type qualifier. In
order to implement, only a few changes have to be done in ASTContext and
CodeGen and RecordLayoutBuilder.

However these changes may impact the code generation in unexpected ways in
particular under -fms-extensions (as __unaligned is ignored/unimplemented in
x86/x86-64 by Visual Studio). So in principle this feature would not be enabled
by default. Instead we suggest to conditionalize the code generation of
__unaligned declarations and expressions under -fhonor-unaligned-qualifier (in
lack of a better name, suggestions welcome).

Our current implementation shows that these changes have minor impact in
clang's codebase itself as most of the cases are just an extra check for a
qualifier that was already there. Also the changes are easy to spot
as they are conditionalized by a LangOpts called HonorUnaligned.

Currently, there is no support for the mangling of __packed type qualifier in
C++ (at least for the Itanium ABI). We do not plan to address this issue in
this proposal.

3. Feedback request
-------------------

We are very interested in feedback about how interesting and useful this
feature is to have upstream. Also we'd like to gather comments about the
potential impact in other areas we may have missed. Suggestions for
improvements are strongly welcome as well.

Kind regards,
Roger

[1] https://msdn.microsoft.com/en-us/library/ms177389.aspx
[2] https://reviews.llvm.org/D20437
_______________________________________________
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: [RFC] Implement code generation for __unaligned

Ammarguellat, Zahira via cfe-dev

> Currently, there is no support for the mangling of __packed type qualifier in

I obviously meant __unaligned. Apologies.

Regards,
Roger
_______________________________________________
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: [RFC] Implement code generation for __unaligned

Ammarguellat, Zahira via cfe-dev
In reply to this post by Ammarguellat, Zahira via cfe-dev
On 17 Feb 2017 6:15 am, "Roger Ferrer Ibanez via cfe-dev" <[hidden email]> wrote:
Dear all,

this is a proposal to improve the usefulness of clang in the context of systems
programming and embedded systems.

Our goal is to complete the code generation support of the existing __unaligned
support, which is implemented in clang as a Microsoft extension[1] under
-fms-extensions.

We have implemented most of the proposal but we'd want to gather feedback from
the community so we can contribute an implementation that successfully fits the
existing project goals.

1. Context
----------

In low-level programming it is not unusual that objects are in addresses not
aligned to the natural alignment of the data. In some architectures this is
only a performance issue, where unaligned accesses to objects are correct and
may only have to pay a penalty. But in other architectures this is a
correctness issue as these objects must be accessed using special unaligned
instructions. Failing to do so leads to a fault of the program.

Unfortunately the existing support of unaligned data is not very good in
existing C and C++ implementations. clang and gcc, support the aligned(x)
attribute, which can be used to increase or decrease (except for structs) the
alignment of the declared object. This means that it is not possible to have a
pointer to unaligned data easily.

It's actually not too hard; the way to do it is with a typedef:

typedef int __attribute__((aligned(1))) ui;
ui *P;

(Examples assume common 32-bit architectures)

__attribute__((aligned(1))) int *p; // p is aligned(1) but *p is aligned(4)

The implementation of the __unaligned Microsoft extension[2] extended the type
system adding a new "unaligned" type-qualifier but no codegen was implemented
at that time. The goal was mostly parsing the Windows headers.

This proposal suggests to implement the missing parts of it, so it becomes
useful for architectures where unaligned accesses pose a correctness issue.

__unaligned int *p1; // p1 is aligned(4) *p1 is aligned(1)
int * __unaligned p2; // p2 is aligned(1), *p2 is aligned(4)
__unaligned int *__unaligned p3; // p3 is aligned(1), *p3 is aligned(1)
__unaligned int a[N]; // a[e] is aligned(1)

2. Proposal
-----------

Our proposal is basically implement the missing CodeGen bits for __unaligned.

OK.

Currently clang's codegen is oblivious to the unaligned type qualifier. In
order to implement, only a few changes have to be done in ASTContext and
CodeGen and RecordLayoutBuilder.

However these changes may impact the code generation in unexpected ways in
particular under -fms-extensions (as __unaligned is ignored/unimplemented in
x86/x86-64 by Visual Studio). So in principle this feature would not be enabled
by default. Instead we suggest to conditionalize the code generation of
__unaligned declarations and expressions under -fhonor-unaligned-qualifier (in
lack of a better name, suggestions welcome).

I don't really see the need for a flag to control this. What unexpected changes to the generated code are you concerned about?

Our current implementation shows that these changes have minor impact in
clang's codebase itself as most of the cases are just an extra check for a
qualifier that was already there. Also the changes are easy to spot
as they are conditionalized by a LangOpts called HonorUnaligned.

Currently, there is no support for the mangling of __packed type qualifier in
C++ (at least for the Itanium ABI). We do not plan to address this issue in
this proposal.

3. Feedback request
-------------------

We are very interested in feedback about how interesting and useful this
feature is to have upstream. Also we'd like to gather comments about the
potential impact in other areas we may have missed. Suggestions for
improvements are strongly welcome as well.

Kind regards,
Roger

[1] https://msdn.microsoft.com/en-us/library/ms177389.aspx
[2] https://reviews.llvm.org/D20437
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
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: [RFC] Implement code generation for __unaligned

Ammarguellat, Zahira via cfe-dev
In reply to this post by Ammarguellat, Zahira via cfe-dev
I don't think we want __unaligned to affect record layout, we just want it to affect the alignment used when loading and storing an unaligned type. That's the way I read the MSDN description of __unaligned. I don't think Clang should implement its own, different semantics from MSVC for __unaligned. That causes confusion and the compatibility issues you mention.

I think programmers already have enough tools to control record layout. They have __attribute__((packed)) and __attribute__((aligned(N))). What they don't have are good tools to take unaligned pointers from code they don't control and access them safely. The MSVC version of __unaligned lets you do that, so I think we should just finish implementing it as described and call it a day.

_______________________________________________
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: [RFC] Implement code generation for __unaligned

Ammarguellat, Zahira via cfe-dev

Hi all,

 

thanks for the feedback.

 

Richard: On a second thought, it looks like it may not have much impact in the code generation, at least in x86. This was just in case unaligned accesses start to appear in other targets. But maybe I’m being too cautious here. So I will drop the flag from the patch.

 

Reid: I agree that there is enough machinery now for packed fields and __unaligned would add little here. I will be dropping this from the patch as well.

 

Kind regards,

Roger

 

 

From: Reid Kleckner [mailto:[hidden email]]
Sent: 17 February 2017 17:48
To: Roger Ferrer Ibanez
Cc: [hidden email]; nd
Subject: Re: [cfe-dev] [RFC] Implement code generation for __unaligned

 

I don't think we want __unaligned to affect record layout, we just want it to affect the alignment used when loading and storing an unaligned type. That's the way I read the MSDN description of __unaligned. I don't think Clang should implement its own, different semantics from MSVC for __unaligned. That causes confusion and the compatibility issues you mention.

 

I think programmers already have enough tools to control record layout. They have __attribute__((packed)) and __attribute__((aligned(N))). What they don't have are good tools to take unaligned pointers from code they don't control and access them safely. The MSVC version of __unaligned lets you do that, so I think we should just finish implementing it as described and call it a day.


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