<div dir="auto"><div><div class="gmail_extra"><div class="gmail_quote">On 17 Feb 2017 6:15 am, "Roger Ferrer Ibanez via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear all,<br>
<br>
this is a proposal to improve the usefulness of clang in the context of systems<br>
programming and embedded systems.<br>
<br>
Our goal is to complete the code generation support of the existing __unaligned<br>
support, which is implemented in clang as a Microsoft extension[1] under<br>
-fms-extensions.<br>
<br>
We have implemented most of the proposal but we'd want to gather feedback from<br>
the community so we can contribute an implementation that successfully fits the<br>
existing project goals.<br>
<br>
1. Context<br>
----------<br>
<br>
In low-level programming it is not unusual that objects are in addresses not<br>
aligned to the natural alignment of the data. In some architectures this is<br>
only a performance issue, where unaligned accesses to objects are correct and<br>
may only have to pay a penalty. But in other architectures this is a<br>
correctness issue as these objects must be accessed using special unaligned<br>
instructions. Failing to do so leads to a fault of the program.<br>
<br>
Unfortunately the existing support of unaligned data is not very good in<br>
existing C and C++ implementations. clang and gcc, support the aligned(x)<br>
attribute, which can be used to increase or decrease (except for structs) the<br>
alignment of the declared object. This means that it is not possible to have a<br>
pointer to unaligned data easily.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">It's actually not too hard; the way to do it is with a typedef:</div><div dir="auto"><br></div><div dir="auto"><div dir="auto">typedef int __attribute__((aligned(1))) ui;</div><div dir="auto">ui *P;</div><div dir="auto"><br></div></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(Examples assume common 32-bit architectures)<br>
<br>
__attribute__((aligned(1))) int *p; // p is aligned(1) but *p is aligned(4)<br>
<br>
The implementation of the __unaligned Microsoft extension[2] extended the type<br>
system adding a new "unaligned" type-qualifier but no codegen was implemented<br>
at that time. The goal was mostly parsing the Windows headers.<br>
<br>
This proposal suggests to implement the missing parts of it, so it becomes<br>
useful for architectures where unaligned accesses pose a correctness issue.<br>
<br>
__unaligned int *p1; // p1 is aligned(4) *p1 is aligned(1)<br>
int * __unaligned p2; // p2 is aligned(1), *p2 is aligned(4)<br>
__unaligned int *__unaligned p3; // p3 is aligned(1), *p3 is aligned(1)<br>
__unaligned int a[N]; // a[e] is aligned(1)<br>
<br>
2. Proposal<br>
-----------<br>
<br>
Our proposal is basically implement the missing CodeGen bits for __unaligned.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">OK.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Currently clang's codegen is oblivious to the unaligned type qualifier. In<br>
order to implement, only a few changes have to be done in ASTContext and<br>
CodeGen and RecordLayoutBuilder.<br>
<br>
However these changes may impact the code generation in unexpected ways in<br>
particular under -fms-extensions (as __unaligned is ignored/unimplemented in<br>
x86/x86-64 by Visual Studio). So in principle this feature would not be enabled<br>
by default. Instead we suggest to conditionalize the code generation of<br>
__unaligned declarations and expressions under -fhonor-unaligned-qualifier (in<br>
lack of a better name, suggestions welcome).<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I don't really see the need for a flag to control this. What unexpected changes to the generated code are you concerned about?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Our current implementation shows that these changes have minor impact in<br>
clang's codebase itself as most of the cases are just an extra check for a<br>
qualifier that was already there. Also the changes are easy to spot<br>
as they are conditionalized by a LangOpts called HonorUnaligned.<br>
<br>
Currently, there is no support for the mangling of __packed type qualifier in<br>
C++ (at least for the Itanium ABI). We do not plan to address this issue in<br>
this proposal.<br>
<br>
3. Feedback request<br>
-------------------<br>
<br>
We are very interested in feedback about how interesting and useful this<br>
feature is to have upstream. Also we'd like to gather comments about the<br>
potential impact in other areas we may have missed. Suggestions for<br>
improvements are strongly welcome as well.<br>
<br>
Kind regards,<br>
Roger<br>
<br>
[1] <a href="https://msdn.microsoft.com/en-us/library/ms177389.aspx" rel="noreferrer" target="_blank">https://msdn.microsoft.com/en-<wbr>us/library/ms177389.aspx</a><br>
[2] <a href="https://reviews.llvm.org/D20437" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D20437</a><br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div></div></div>