SuccessChanges

Changes from Git (git http://labmaster3.local/git/llvm-project.git)

Summary

  1. [ARM] Follow AACPS standard for volatile bit-fields access width (details)
Commit 6a24339a45246b66bd3de88cc9c6a5b5e77c0645 by diogo.sampaio
[ARM] Follow AACPS standard for volatile bit-fields access width
Summary: This patch resumes the work of D16586. According to the AAPCS,
volatile bit-fields should be accessed using containers of the widht of
their declarative type. In such case:
``` struct S1 {
short a : 1;
}
``` should be accessed using load and stores of the width
(sizeof(short)), where now the compiler does only load the minimum
required width (char in this case). However, as discussed in D16586,
that could overwrite non-volatile bit-fields, which conflicted with C
and C++ object models by creating data race conditions that are not part
of the bit-field, e.g.
``` struct S2 {
short a;
int  b : 16;
}
``` Accessing `S2.b` would also access `S2.a`.
The AAPCS Release 2019Q1.1
(https://static.docs.arm.com/ihi0042/g/aapcs32.pdf) section 8.1 Data
Types, page 35, "Volatile bit-fields - preserving number and width of
container accesses" has been updated to avoid conflict with the C++
Memory Model. Now it reads in the note:
``` This ABI does not place any restrictions on the access widths of
bit-fields where the container overlaps with a non-bit-field member.
This is because the C/C++ memory model defines these as being separate
memory locations, which can be accessed by two threads
simultaneously. For this reason, compilers must be permitted to use a
narrower memory access width (including splitting the access
into multiple instructions) to avoid writing to a different memory
location.
```
I've updated the patch D16586 to follow such behavior by verifying that
we only change volatile bit-field access when:
- it won't overlap with any other non-bit-field member
- we only access memory inside the bounds of the record
Regarding the number of memory accesses, that should be preserved, that
will be implemented by D67399.
Reviewers: rsmith, rjmccall, eli.friedman, ostannard
Subscribers: ostannard, kristof.beyls, cfe-commits, carwil, olista01
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72932
The file was modifiedclang/lib/CodeGen/CGExpr.cpp
The file was modifiedclang/test/CodeGen/aapcs-bitfield.c
The file was modifiedclang/lib/CodeGen/CodeGenFunction.h
The file was modifiedclang/lib/CodeGen/CGValue.h