[cfe-dev] [RFC] Implement code generation for __unaligned

[Richard Smith via cfe-dev]

On 17 Feb 2017 6:15 am, "Roger Ferrer Ibanez via cfe-dev" <
cfe-dev at lists.llvm.org> 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
cfe-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170217/e16d7e9b/attachment.html>